{ "corpus": "orca-products", "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." }, "definition": "A product is a named way of using a rail that a customer or a business sets up or enters separately from the rail's ordinary payment, and that has at least one object of its own the ordinary payment lacks: an authorisation that outlives one payment, a lifecycle that runs before or beside the payment, or a code set of its own. Its money still moves as the rail moves it, under the rail's own authority.", "derivation": { "anchor": "A TransactionType is a product when it has an anchor of its own: a Mandate whose only authorises link is that type; or two or more LifecycleStates whose governed_by links all land on Rules that apply to that type alone, or on its own Mandate and that Mandate's Rules; or a CodeSet whose see_also links all land there.", "sec_code": "A TransactionType that carries a sec_code is the rail's own entry class, whatever authorisation rules it has, and is never a product.", "floor": 5, "floor_meaning": "The floor of 5 Rules is a page threshold and no part of the definition: below it a derived page tells a reader nothing they can use. A product with fewer Rules is still a product; it is listed as one with too few records held to render a page.", "members": "A product's records are the Rules that apply to its TransactionType, the Rules reached through its own Mandate (governed_by, revoked_via, evidenced_by), its own Mandates, LifecycleStates and CodeSets, any ReasonCode that applies to it, and the Roles those bind or name. A record whose links also land outside the product is shared with the rail and is shown as inherited, never as the product's own.", "view": "Nothing on a product view is written by the build beyond labels and counts. Every sentence is a record's own, and the view carries no status, confidence or corroboration of its own: those belong to the records, and each is shown with its own." }, "counts": { "products": 6, "rendered": 6, "thin": 0, "candidates": 25, "entry_classes": 2, "rails": 5 }, "page_path": "{rail}/{slug}.html", "file_path": "data/products/{rail}/{slug}.json", "products": [ { "uid": "au-npp:txn.mandate-payment", "id": "txn.mandate-payment", "slug": "mandate-payment", "rail": "au-npp", "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "page": "au-npp/mandate-payment.html", "file": "data/products/au-npp/mandate-payment.json", "name": "Mandate Payment (PayTo)", "anchor": "3 authorisations of its own, a lifecycle of its own (5 states)", "transaction_type": { "uid": "au-npp:txn.mandate-payment", "name": "Mandate Payment (PayTo)", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "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.", "directions": [ "credit" ], "account_types": [ "any" ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "the Part 17 preamble and Regulations 17.1(b) and (c), and 17.8(b)" } ] }, "counts": { "rules": 18, "mandates": 3, "states": 5, "code_sets": 0, "reason_codes": 6, "roles": 9, "members": 33 }, "trust": { "members": 33, "by_status": { "draft": 1, "corroborated": 32, "verified": 0, "superseded": 0 }, "strongest_source_class": "authoritative_primary" }, "roles": [ { "uid": "au-npp:role.connected-institution", "name": "Connected Institution", "kind": "institution", "via": [ "binds" ] }, { "uid": "au-npp:role.initiating-participant", "name": "Initiating Participant", "kind": "institution", "via": [ "binds" ] }, { "uid": "au-npp:role.mps-user", "name": "MPS User", "kind": "party", "via": [ "given_to", "binds" ] }, { "uid": "au-npp:role.nppa", "name": "NPP Australia Limited (NPPA)", "kind": "operator", "via": [ "binds" ] }, { "uid": "au-npp:role.overlay-service-provider", "name": "Overlay Service Provider", "kind": "service_provider", "via": [ "binds" ] }, { "uid": "au-npp:role.payer-customer", "name": "Payer Customer", "kind": "party", "via": [ "given_by", "binds" ] }, { "uid": "au-npp:role.payer-participant", "name": "Payer Participant", "kind": "institution", "via": [ "given_to", "binds" ] }, { "uid": "au-npp:role.payment-initiator", "name": "Payment Initiator", "kind": "service_provider", "via": [ "binds" ] }, { "uid": "au-npp:role.sponsor", "name": "Sponsor", "kind": "institution", "via": [ "binds" ] } ], "mandates": [ { "uid": "au-npp:mandate.authorised-payment-mandate", "name": "Authorised Payment Mandate (a PayTo agreement)", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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." } }, "governed_by": [ { "uid": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "name": "A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps" }, { "uid": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "name": "Offering PayTo is optional for a creditor's bank and compulsory for the payer's bank" }, { "uid": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "name": "The payer's institution must deliver the authorisation request to the payer in near real time" }, { "uid": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "name": "No payment request may be sent unless the mandate is active" }, { "uid": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "name": "A change to the amount or the frequency has to come from the business as a fresh agreement" }, { "uid": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "name": "A mandate may be moved to another institution without the authorisation changing" }, { "uid": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "name": "A mandate record is confidential to its parties and may be looked up only by them" }, { "uid": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "name": "A claim about an ordinary mandate is tested against the record, or against evidence the initiator must produce" } ], "revoked_via": [ { "uid": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "name": "The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates" } ], "evidenced_by": [ { "uid": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "name": "The mandate record is the evidence of the amount, the frequency and the beneficiary" } ], "disputed_via": [ { "uid": "au-npp:exc.mandate-claim", "name": "Mandate claim", "shared": true } ], "given_by": [ { "uid": "au-npp:role.payer-customer", "name": "Payer Customer", "note": null } ], "given_to": [ { "uid": "au-npp:role.mps-user", "name": "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." } ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "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" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "what a PayTo agreement is, how PayTo works, and managing agreements" } ] }, { "uid": "au-npp:mandate.debtor-payment-arrangement", "name": "Debtor Payment Arrangement", "status": "draft", "stored_status": "draft", "source_class": null, "confidence": "low", "tier": { "k": "draft", "label": "Draft, unchecked", "say": "An agent wrote this from published material and nobody has checked it. NPP Australia Limited's own text was not the source for this record. Treat it as a lead to confirm, not an answer, before acting on any retry, deadline or rate." }, "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" ], "constraints": null, "governed_by": [ { "uid": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "name": "A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps" } ], "revoked_via": [], "evidenced_by": [], "disputed_via": [], "given_by": [ { "uid": "au-npp:role.payer-customer", "name": "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." } ], "given_to": [ { "uid": "au-npp:role.payer-participant", "name": "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." } ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.1(b) final paragraph, Regulation 17.8(f), and the definition of Debtor Payment Arrangement, which points at the NPP Procedures" } ] }, { "uid": "au-npp:mandate.migrated-ddr-mandate", "name": "Migrated DDR Mandate", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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." } }, "governed_by": [ { "uid": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "name": "A migrated direct debit mandate is created unilaterally and is active the moment it exists" }, { "uid": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "name": "A migrated mandate needs written notice to the payer first, at least 14 days ahead" }, { "uid": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "name": "A migrated mandate may not be used for a payment request until 5 days after it was created" }, { "uid": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "name": "Until the payer says something, their institution must keep processing a migrated mandate" }, { "uid": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "name": "A claim about a migrated mandate is deemed substantiated unless the sponsor produces the evidence" }, { "uid": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "name": "No payment request may be sent unless the mandate is active" }, { "uid": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "name": "A mandate record is confidential to its parties and may be looked up only by them" } ], "revoked_via": [ { "uid": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "name": "The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates" } ], "evidenced_by": [ { "uid": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "name": "The mandate record is the evidence of the amount, the frequency and the beneficiary" } ], "disputed_via": [ { "uid": "au-npp:exc.mandate-claim", "name": "Mandate claim", "shared": true } ], "given_by": [ { "uid": "au-npp:role.payer-customer", "name": "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." } ], "given_to": [ { "uid": "au-npp:role.mps-user", "name": "MPS User", "note": null } ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.4(a) to (f), 17.6(c)(viii) and 17.10(c)(ii) and (e)" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "moving direct debits to PayTo agreements" } ] } ], "states": [ { "uid": "au-npp:state.mandate-awaiting-authorisation", "name": "PayTo agreement: created, awaiting the payer's authorisation", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [ { "uid": "au-npp:state.mandate-active", "name": "PayTo agreement: active" }, { "uid": "au-npp:state.mandate-declined", "name": "PayTo agreement: declined by the payer" } ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.6(c)(i) to (v), 17.6(c)(viii) and 17.8(b), and the definition of Active in 1.1" }, { "uid": "au-npp:src.npp-payto-service-overview-v2", "name": "NPP Australia, PayTo Service Overview v2.0, November 2021", "url": "https://www.auspayplus.com.au/wp-content/uploads/2025/07/PayTo-Service-Overview-Nov-2021-2.0.pdf", "source_class": "public_primary", "edition": "v2.0, November 2021 (PDF created 2021-11-23), re-uploaded July 2025", "section": "page 7 and the worked examples on pages 18 to 21" } ] }, { "uid": "au-npp:state.mandate-declined", "name": "PayTo agreement: declined by the payer", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "low", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.6(c)(v) and 17.8(b)" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "what if the details of the PayTo agreement are wrong" } ] }, { "uid": "au-npp:state.mandate-active", "name": "PayTo agreement: active", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [ { "uid": "au-npp:state.mandate-suspended", "name": "PayTo agreement: suspended (paused)" }, { "uid": "au-npp:state.mandate-cancelled", "name": "PayTo agreement: cancelled" } ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "definition of Active in 1.1; Regulations 17.4(b), 17.6(c)(v) and (vii), and 17.8(b)" }, { "uid": "au-npp:src.npp-payto-service-overview-v2", "name": "NPP Australia, PayTo Service Overview v2.0, November 2021", "url": "https://www.auspayplus.com.au/wp-content/uploads/2025/07/PayTo-Service-Overview-Nov-2021-2.0.pdf", "source_class": "public_primary", "edition": "v2.0, November 2021 (PDF created 2021-11-23), re-uploaded July 2025", "section": "pages 7 and 8" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "can I change, pause, resume or cancel my PayTo agreement" } ] }, { "uid": "au-npp:state.mandate-suspended", "name": "PayTo agreement: suspended (paused)", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [ { "uid": "au-npp:state.mandate-active", "name": "PayTo agreement: active" }, { "uid": "au-npp:state.mandate-cancelled", "name": "PayTo agreement: cancelled" } ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.4(d)(iii), 17.6(c)(vii) and (d), and 17.10(c)(i)(B)" }, { "uid": "au-npp:src.npp-payto-service-overview-v2", "name": "NPP Australia, PayTo Service Overview v2.0, November 2021", "url": "https://www.auspayplus.com.au/wp-content/uploads/2025/07/PayTo-Service-Overview-Nov-2021-2.0.pdf", "source_class": "public_primary", "edition": "v2.0, November 2021 (PDF created 2021-11-23), re-uploaded July 2025", "section": "pages 5, 8 and 10" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "can I change, pause, resume or cancel my PayTo agreement" } ] }, { "uid": "au-npp:state.mandate-cancelled", "name": "PayTo agreement: cancelled", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.6(c)(vii) and (d), 17.7(b)(iv) and 17.10(c)(i)(B)" }, { "uid": "au-npp:src.npp-payto-service-overview-v2", "name": "NPP Australia, PayTo Service Overview v2.0, November 2021", "url": "https://www.auspayplus.com.au/wp-content/uploads/2025/07/PayTo-Service-Overview-Nov-2021-2.0.pdf", "source_class": "public_primary", "edition": "v2.0, November 2021 (PDF created 2021-11-23), re-uploaded July 2025", "section": "page 8" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "can I change, pause, resume or cancel my PayTo agreement" } ] } ], "code_sets": [], "reason_codes": [ { "uid": "au-npp-reject:AG01", "name": "Transaction forbidden", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "id": "AG01", "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.", "sources": [] }, { "uid": "au-npp-reject:AM06", "name": "Too low amount", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "id": "AM06", "summary": "The amount asked for is below the minimum the PayTo agreement allows. A PayTo specific meaning that the ISO definition does not carry.", "sources": [] }, { "uid": "au-npp-reject:AM09", "name": "Wrong amount", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "id": "AM09", "summary": "The amount in a PayTo payment request is not the amount the agreement agreed or expected. Another PayTo specific meaning.", "sources": [] }, { "uid": "au-npp-reject:AM21", "name": "Limit exceeded", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "id": "AM21", "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.", "sources": [] }, { "uid": "au-npp-reject:MD01", "name": "No mandate", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "id": "MD01", "summary": "The PayTo agreement identifier is missing from the payment instruction. A payment request under an agreement has to name the agreement.", "sources": [] }, { "uid": "au-npp-reject:NAUT", "name": "Not authorised", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "id": "NAUT", "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.", "sources": [] } ], "rules": [ { "uid": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "name": "The paying institution cannot cancel or recall a payment once the message is in its own gateway", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "finality", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "au-npp:txn.bsct", "name": "Basic Single Credit Transfer (BSCT)" }, { "uid": "au-npp:txn.os-payment", "name": "Overlay Service Payment (OS Payment)" } ], "parameters": [], "part_of": [ "au-npp:exc.settlement-rejection" ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 6.2(a)" } ] }, { "uid": "au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "name": "A rejected mandate payment initiation request must also carry a valid and applicable reason code", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.8(b)(i) and (ii)" } ] }, { "uid": "au-npp:rule.messages-iso-20022-from-launch", "name": "The platform has used ISO 20022 natively since launch", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "au-npp:txn.bsct", "name": "Basic Single Credit Transfer (BSCT)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "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)" }, { "uid": "au-npp:src.npp-payment-initiation-messages-v4", "name": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "edition": "v4.0, 20 November 2025, uploaded March 2026", "section": "Background" } ] }, { "uid": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "name": "A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.1(a) and (b), and Regulation 17.1(g)" } ] }, { "uid": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "name": "A mandate may be moved to another institution without the authorisation changing", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.6(c)(vi), 17.5(f) and 17.7(b)(iv), and the Part 17 drafting note on porting" } ] }, { "uid": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "name": "A claim about a migrated mandate is deemed substantiated unless the sponsor produces the evidence", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [ "au-npp:exc.mandate-claim" ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.10(c)(ii) and 17.10(e)" } ] }, { "uid": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "name": "A migrated direct debit mandate is created unilaterally and is active the moment it exists", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.4(a), (b) and (d), and 17.6(c)(viii)" } ] }, { "uid": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "name": "No payment request may be sent unless the mandate is active", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [ "au-npp:exc.mandate-claim" ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.8(a), (b) and (c), and 17.10(c)(i)(B)" } ] }, { "uid": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "name": "A change to the amount or the frequency has to come from the business as a fresh agreement", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "guidance", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "can I change, pause, resume or cancel my PayTo agreement" }, { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.6(d), on a maintenance function being permitted by the mandate's terms" } ] }, { "uid": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "name": "A claim about an ordinary mandate is tested against the record, or against evidence the initiator must produce", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [ "au-npp:exc.mandate-claim" ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.10(f)(i) and (ii), and Regulation 17.10(c)(i)" } ] }, { "uid": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "name": "The payer's institution must deliver the authorisation request to the payer in near real time", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.6(c)(i) to (v), and the definition of Active" } ] }, { "uid": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "name": "A mandate record is confidential to its parties and may be looked up only by them", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulations 17.2(e) and 17.7(a) and (b)" } ] }, { "uid": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "name": "A migrated mandate may not be used for a payment request until 5 days after it was created", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "time_window", "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]." } ], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.4(e)" } ] }, { "uid": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "name": "A migrated mandate needs written notice to the payer first, at least 14 days ahead", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [ { "kind": "time_window", "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]." } ], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.4(c)(i) to (iii)" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "what should I do if my direct debit is moving to PayTo, and do I have to agree" } ] }, { "uid": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "name": "Offering PayTo is optional for a creditor's bank and compulsory for the payer's bank", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.1(f)(i) to (iv) and Regulation 17.1(n)" } ] }, { "uid": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "name": "The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.6(c)(vii) and 17.6(d)" }, { "uid": "au-npp:src.auspayplus-payto-faqs", "name": "Australian Payments Plus, PayTo FAQs", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "edition": "live page, read 2026-09-21", "section": "can I change, pause, resume or cancel my PayTo agreement" } ] }, { "uid": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "name": "Until the payer says something, their institution must keep processing a migrated mandate", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.4(d)(i) to (iv)" } ] }, { "uid": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "name": "The mandate record is the evidence of the amount, the frequency and the beneficiary", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of NPP Australia Limited itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [ "au-npp:exc.mandate-claim" ], "sources": [ { "uid": "au-npp:src.npp-regulations-v21", "name": "Regulations for the New Payments Platform, v21.0, public version", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "section": "Regulation 17.10(d)" } ] } ], "inherited": [ { "facet": "settlement", "label": "Settlement", "question": "How and when does the money settle between institutions?", "fact_uid": "au-npp:settlement", "fact_name": "How and when does an NPP payment settle?" }, { "facet": "hours", "label": "Hours", "question": "When does the rail run, and what are its cut-offs?", "fact_uid": "au-npp:hours", "fact_name": "When is the NPP open?" }, { "facet": "limits", "label": "Limits", "question": "What limits apply to a payment, and who sets them?", "fact_uid": "au-npp:limits", "fact_name": "Is there a limit on an NPP payment?" }, { "facet": "return", "label": "Return", "question": "How does a payment come back, and on what deadline?", "fact_uid": "au-npp:return", "fact_name": "How does money come back on the NPP?" }, { "facet": "recall", "label": "Recall", "question": "Can the sender ask for a payment back, and who decides?", "fact_uid": "au-npp:recall", "fact_name": "Can an NPP payment be recalled?" }, { "facet": "refund", "label": "Refund", "question": "Can the payer get the money back, and on what right?", "fact_uid": "au-npp:refund", "fact_name": "Can a customer get an NPP payment refunded?" }, { "facet": "liability", "label": "Liability", "question": "Who bears a loss when something goes wrong?", "fact_uid": "au-npp:liability", "fact_name": "Who bears the loss on an NPP payment?" }, { "facet": "consumer-law", "label": "Consumer law", "question": "What does the law give a consumer here, beyond the rulebook?", "fact_uid": "au-npp:consumer-law", "fact_name": "What consumer law sits above the NPP?" }, { "facet": "participants", "label": "Participants", "question": "Who may take part, and in what role?", "fact_uid": "au-npp:participants", "fact_name": "Who takes part in the NPP?" }, { "facet": "decision-points", "label": "Human decision points", "question": "Where does a rule leave the decision to a bank or a person?", "fact_uid": "au-npp:decision-points", "fact_name": "Where does somebody decide something on the NPP?" } ], "differs": [ { "facet": "finality", "label": "Finality", "fact_uid": "au-npp:finality", "fact_name": "When is an NPP payment final, and can it be undone?", "rules": [ { "uid": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "name": "The paying institution cannot cancel or recall a payment once the message is in its own gateway" } ] }, { "facet": "liability", "label": "Liability", "fact_uid": "au-npp:liability", "fact_name": "Who bears the loss on an NPP payment?", "rules": [ { "uid": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "name": "A claim about a migrated mandate is deemed substantiated unless the sponsor produces the evidence" }, { "uid": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "name": "A claim about an ordinary mandate is tested against the record, or against evidence the initiator must produce" } ] }, { "facet": "messages", "label": "Messages", "fact_uid": "au-npp:messages", "fact_name": "What messages does the NPP use, and what codes do they carry?", "rules": [ { "uid": "au-npp:rule.messages-iso-20022-from-launch", "name": "The platform has used ISO 20022 natively since launch" }, { "uid": "au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "name": "A rejected mandate payment initiation request must also carry a valid and applicable reason code" } ] }, { "facet": "decision-points", "label": "Human decision points", "fact_uid": "au-npp:decision-points", "fact_name": "Where does somebody decide something on the NPP?", "rules": [ { "uid": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "name": "A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps" }, { "uid": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "name": "Offering PayTo is optional for a creditor's bank and compulsory for the payer's bank" }, { "uid": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "name": "The payer's institution must deliver the authorisation request to the payer in near real time" }, { "uid": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "name": "No payment request may be sent unless the mandate is active" }, { "uid": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "name": "The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates" }, { "uid": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "name": "A change to the amount or the frequency has to come from the business as a fresh agreement" }, { "uid": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "name": "A mandate may be moved to another institution without the authorisation changing" }, { "uid": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "name": "A mandate record is confidential to its parties and may be looked up only by them" }, { "uid": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "name": "The mandate record is the evidence of the amount, the frequency and the beneficiary" }, { "uid": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "name": "A migrated direct debit mandate is created unilaterally and is active the moment it exists" }, { "uid": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "name": "A migrated mandate needs written notice to the payer first, at least 14 days ahead" }, { "uid": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "name": "A migrated mandate may not be used for a payment request until 5 days after it was created" }, { "uid": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "name": "Until the payer says something, their institution must keep processing a migrated mandate" } ] } ], "exceptions": [ { "uid": "au-npp:exc.mandate-claim", "name": "Mandate claim", "shared": true, "via": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "disputed_via" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "disputed_via" }, { "from": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "type": "part_of" }, { "from": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "type": "part_of" }, { "from": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "type": "part_of" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "type": "part_of" } ] }, { "uid": "au-npp:exc.settlement-rejection", "name": "Settlement rejection, which voids a cleared payment", "shared": true, "via": [ { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "part_of" } ] } ] }, { "uid": "blik:txn.recurring", "id": "txn.recurring", "slug": "recurring", "rail": "blik", "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "page": "blik/recurring.html", "file": "data/products/blik/recurring.json", "name": "Recurring transaction", "anchor": "an authorisation of its own, a lifecycle of its own (3 states)", "transaction_type": { "uid": "blik:txn.recurring", "name": "Recurring transaction", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "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", "directions": [ "debit" ], "account_types": [ "any" ], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "Recurring Payment and Recurring Transaction; implementation models" }, { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§2 (definition of Akceptant a, second indent)" } ] }, "counts": { "rules": 33, "mandates": 1, "states": 3, "code_sets": 0, "reason_codes": 0, "roles": 7, "members": 38 }, "trust": { "members": 38, "by_status": { "draft": 2, "corroborated": 36, "verified": 0, "superseded": 0 }, "strongest_source_class": "authoritative_primary" }, "roles": [ { "uid": "blik:role.acquirer", "name": "Acquirer (Agent Rozliczeniowy)", "kind": "institution", "via": [ "binds" ] }, { "uid": "blik:role.issuer", "name": "Issuer (Wydawca)", "kind": "institution", "via": [ "binds" ] }, { "uid": "blik:role.mastercard-cooperating-scheme", "name": "Mastercard, the Cooperating Scheme (Schemat Współpracujący)", "kind": "operator", "via": [ "binds" ] }, { "uid": "blik:role.merchant", "name": "Merchant or acceptant (Akceptant)", "kind": "party", "via": [ "given_to", "binds" ] }, { "uid": "blik:role.psp", "name": "Polski Standard Płatności S.A. (PSP), operator", "kind": "operator", "via": [ "binds" ] }, { "uid": "blik:role.settlement-entity", "name": "Settlement entity (Podmiot Rozrachunkowy)", "kind": "institution", "via": [ "binds" ] }, { "uid": "blik:role.user", "name": "User (Użytkownik)", "kind": "party", "via": [ "given_by" ] } ], "mandates": [ { "uid": "blik:mandate.recurring-payment", "name": "BLIK recurring payment (Płatność powtarzalna BLIK)", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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" ], "constraints": null, "governed_by": [ { "uid": "blik:rule.recurring-models", "name": "Recurring payment models A, M and O" }, { "uid": "blik:rule.recurring-retry-72-hours", "name": "Recurring transaction short of funds: 72 hours of bank retries" }, { "uid": "blik:rule.recurring-flags", "name": "Recurring payment flags and the one public BLIK error code" }, { "uid": "blik:rule.issuer-decides-authorisation", "name": "The issuer decides; an acquirer's no-confirmation hint is only advice" } ], "revoked_via": [ { "uid": "blik:rule.recurring-cancel-in-banking-app", "name": "Recurring payment: the user sees and cancels it in the bank app" } ], "evidenced_by": [ { "uid": "blik:rule.recurring-consent-in-banking-app", "name": "Recurring payment: consent started at the merchant, confirmed in the bank app" } ], "disputed_via": [ { "uid": "blik:exc.complaint", "name": "Complaint (reklamacja)", "shared": true } ], "given_by": [ { "uid": "blik:role.user", "name": "User (Użytkownik)", "note": null } ], "given_to": [ { "uid": "blik:role.merchant", "name": "Merchant or acceptant (Akceptant)", "note": null } ], "sources": [] } ], "states": [ { "uid": "blik:state.recurring-payment-active", "name": "BLIK recurring payment: active", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [ { "uid": "blik:state.recurring-payment-deleted-by-user", "name": "BLIK recurring payment: deleted by the user" }, { "uid": "blik:state.recurring-payment-expired", "name": "BLIK recurring payment: past its expiry date" } ], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "Recurring Payment; implementation models table (expiration row)" }, { "uid": "blik:src.blik-recurring-payments-model-a", "name": "BLIK Recurring Payments: Model A", "url": "https://www.blik.com/lp/reccuring-payments/Model-A.141951045.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "how it works; invitation data (alias expiration date)" }, { "uid": "blik:src.blik-faq", "name": "BLIK FAQ (blik.com/faq)", "url": "https://www.blik.com/faq", "source_class": "public_primary", "edition": "live page as read 2026-09-19", "section": "recurring payment questions (starting, details of stored recurring payments, changing bank)" } ] }, { "uid": "blik:state.recurring-payment-deleted-by-user", "name": "BLIK recurring payment: deleted by the user", "status": "draft", "stored_status": "draft", "source_class": null, "confidence": "medium", "tier": { "k": "draft", "label": "Draft, unchecked", "say": "An agent wrote this from published material and nobody has checked it. Treat it as a lead to confirm, not an answer, before acting on any retry, deadline or rate." }, "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, "precedes": [], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "Recurring Payment" }, { "uid": "blik:src.blik-faq", "name": "BLIK FAQ (blik.com/faq)", "url": "https://www.blik.com/faq", "source_class": "public_primary", "edition": "live page as read 2026-09-19", "section": "recurring payment questions (giving up a recurring payment)" } ] }, { "uid": "blik:state.recurring-payment-expired", "name": "BLIK recurring payment: past its expiry date", "status": "draft", "stored_status": "draft", "source_class": null, "confidence": "low", "tier": { "k": "draft", "label": "Draft, unchecked", "say": "An agent wrote this from published material and nobody has checked it. Treat it as a lead to confirm, not an answer, before acting on any retry, deadline or rate." }, "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, "precedes": [], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "implementation models table (expiration row)" }, { "uid": "blik:src.blik-recurring-payments-model-a", "name": "BLIK Recurring Payments: Model A", "url": "https://www.blik.com/lp/reccuring-payments/Model-A.141951045.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "how it works; invitation data (alias expiration date)" } ] } ], "code_sets": [], "reason_codes": [], "rules": [ { "uid": "blik:rule.order-entry-and-irrevocable-authorisation", "name": "When a BLIK order is in and when it can no longer be withdrawn", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "finality", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§12.1 to §12.3" } ] }, { "uid": "blik:rule.settlement-order-irrevocable", "name": "The settlement order is entered and fixed at positive authorisation", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "finality", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§29.2 to §29.4; §31.3" } ] }, { "uid": "blik:rule.net-clearing", "name": "Net clearing of BLIK transactions, fees included", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§3.4; §11.1; §16.2; §29.5; §29.8; §29.9; §31.7" }, { "uid": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, multi-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin-1", "source_class": "authoritative_primary", "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", "section": "§16.2; §29.5; §29.9" } ] }, { "uid": "blik:rule.sessions-multi-session-edition", "name": "Clearing and settlement sessions, multi-session model", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, multi-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin-1", "source_class": "authoritative_primary", "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", "section": "§2 (definition of Sesja Rozrachunkowa PSP); §29.6; §29.7; §29.9 to §29.12" } ] }, { "uid": "blik:rule.sessions-single-session-edition", "name": "Clearing sessions, single-session model", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§29.5 to §29.7; §29.9 to §29.13" } ] }, { "uid": "blik:rule.settlement-entity", "name": "Every participant settles through a settlement entity", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§4.1 f to h; §4.3; §31.2" } ] }, { "uid": "blik:rule.settlement-guarantee", "name": "Settlement guarantee among issuers", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§3.10; §7.2 e, f; §31.11 to §31.16" } ] }, { "uid": "blik:rule.sorbnet3-settlement-run", "name": "Settlement in SORBNET3 through PSP's auxiliary account", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§2 (definition of Rachunek Pomocniczy PSP, Rozrachunek); §7.2 a, g; §31.1; §31.4 to §31.10" } ] }, { "uid": "blik:rule.continuous-operation", "name": "The scheme runs around the clock", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§3.1; §3.3; §15; §31.5" } ] }, { "uid": "blik:rule.one-time-code-validity", "name": "How long a one-time BLIK code lives", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 4 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "guidance", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§2 (definition of Kod Jednorazowy); §6 i" }, { "uid": "blik:src.blik-faq", "name": "BLIK FAQ (blik.com/faq)", "url": "https://www.blik.com/faq", "source_class": "public_primary", "edition": "live page as read 2026-09-19", "section": "is BLIK safe" }, { "uid": "blik:src.stripe-blik", "name": "Stripe Docs: BLIK payments", "url": "https://docs.stripe.com/payments/blik", "source_class": "secondary", "edition": "live page as read 2026-09-19", "section": "overview" }, { "uid": "blik:src.adyen-blik", "name": "Adyen Docs: BLIK", "url": "https://docs.adyen.com/payment-methods/blik", "source_class": "secondary", "edition": "live page as read 2026-09-19", "section": "shopper flow, BLIK with code" } ] }, { "uid": "blik:rule.issuer-set-limits", "name": "Each bank sets its users' BLIK limits", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "guidance", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.blik-faq", "name": "BLIK FAQ (blik.com/faq)", "url": "https://www.blik.com/faq", "source_class": "public_primary", "edition": "live page as read 2026-09-19", "section": "whether BLIK works the same in every bank; contactless limits; recurring payment limits" } ] }, { "uid": "blik:rule.per-transaction-limit-unpublished", "name": "Scheme per-transaction limit: set, but not public", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [ "blik:exc.decline" ], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§13; §14.1" } ] }, { "uid": "blik:rule.complaint-ticket-process", "name": "Complaints run from participant to PSP through a ticket system", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "return", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [ "blik:exc.complaint" ], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§6 f, n; §9.1 to §9.4; §9.8; §24.3" } ] }, { "uid": "blik:rule.declined-authorisation-never-settles", "name": "A declined transaction never settles", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "return", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [ "blik:exc.decline" ], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§11.3 f; §14; §29.2" } ] }, { "uid": "blik:rule.cancellation-or-correction-13-months", "name": "Cancellation or correction within 13 months", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "recall", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [ "blik:exc.cancellation-correction" ], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§10; §12.4; §12.5" } ] }, { "uid": "blik:rule.bad-faith-and-crime-liability", "name": "Who answers for bad-faith, criminal or intruder transactions", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§7.4; §8.2 to §8.4" } ] }, { "uid": "blik:rule.complaint-alert-threshold", "name": "Alert when complaints pass 3 percent", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [ { "kind": "limit", "text": "more than 3 percent of the participant's BLIK transactions over 30 days, at least 50 complaints" } ], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§20" } ] }, { "uid": "blik:rule.complaint-fault-pays", "name": "In a complaint the party at fault pays, PSP decides doubt, silence means fault", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [ "blik:exc.complaint" ], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§9.5 to §9.7" } ] }, { "uid": "blik:rule.disputes-over-goods-outside-scheme", "name": "Goods and services disputes stay between user and merchant", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§8.1; §9.9" } ] }, { "uid": "blik:rule.unauthorised-transaction-reporting", "name": "Issuers report unauthorised transactions within two business days", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [ { "kind": "time_window", "text": "within 2 business days of identifying the case" } ], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§7.2 o, p; §24.4" } ] }, { "uid": "blik:rule.issuer-is-users-payment-service-provider", "name": "The issuer is the user's payment service provider", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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].", "facet": "consumer-law", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§1.1; §3.11; §28.1" } ] }, { "uid": "blik:rule.user-complains-to-own-bank", "name": "Users complain to their own bank", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "guidance", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [], "part_of": [ "blik:exc.complaint" ], "sources": [ { "uid": "blik:src.blik-faq", "name": "BLIK FAQ (blik.com/faq)", "url": "https://www.blik.com/faq", "source_class": "public_primary", "edition": "live page as read 2026-09-19", "section": "where to complain" } ] }, { "uid": "blik:rule.authorisation-flows", "name": "Four ways a BLIK authorisation travels", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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].", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§7.2 j, l, m; §11.2 to §11.6" }, { "uid": "blik:src.adyen-blik", "name": "Adyen Docs: BLIK", "url": "https://docs.adyen.com/payment-methods/blik", "source_class": "secondary", "edition": "live page as read 2026-09-19", "section": "BLIK OneClick" } ] }, { "uid": "blik:rule.message-standards-technical-specification", "name": "Message formats and error codes live in the Technical Specification", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§2 (definition of Specyfikacja Techniczna dla Uczestników); §5.1 g, h, m; §6 b, c; §22; list of annexes" } ] }, { "uid": "blik:rule.recurring-flags", "name": "Recurring payment flags and the one public BLIK error code", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [ "blik:exc.decline" ], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "refuseNoPayID mechanism; NODELAY flag" } ] }, { "uid": "blik:rule.recurring-models", "name": "Recurring payment models A, M and O", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "implementation models; supporting banks management" }, { "uid": "blik:src.blik-recurring-payments-model-a", "name": "BLIK Recurring Payments: Model A", "url": "https://www.blik.com/lp/reccuring-payments/Model-A.141951045.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "how it works; frequency; invitation data" } ] }, { "uid": "blik:rule.participant-duties", "name": "What issuers and acquirers must do", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "participants", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§7.1; §7.2 h to n, q, r; §27.5" } ] }, { "uid": "blik:rule.issuer-decides-authorisation", "name": "The issuer decides; an acquirer's no-confirmation hint is only advice", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "decision-points", "rests_on": "rule", "via": "both", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [ "blik:exc.decline" ], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§11.3 e; §11.7" } ] }, { "uid": "blik:rule.psp-fraud-and-gambling-rejection", "name": "PSP rejects on fraud monitoring and blocks illegal gambling domains", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "decision-points", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" } ], "parameters": [], "part_of": [ "blik:exc.decline" ], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§5.1 q; §5.2; §14.2 to §14.4" } ] }, { "uid": "blik:rule.recurring-retry-72-hours", "name": "Recurring transaction short of funds: 72 hours of bank retries", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "decision-points", "rests_on": "guidance", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [ "blik:exc.decline" ], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "unsuccessful recurring transactions; NODELAY flag" }, { "uid": "blik:src.blik-faq", "name": "BLIK FAQ (blik.com/faq)", "url": "https://www.blik.com/faq", "source_class": "public_primary", "edition": "live page as read 2026-09-19", "section": "no money on the account when a recurring payment is due" } ] }, { "uid": "blik:rule.temporary-block", "name": "PSP may block a participant temporarily", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "decision-points", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§21" } ] }, { "uid": "blik:rule.recurring-cancel-in-banking-app", "name": "Recurring payment: the user sees and cancels it in the bank app", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "guidance", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "Recurring Payment" }, { "uid": "blik:src.blik-faq", "name": "BLIK FAQ (blik.com/faq)", "url": "https://www.blik.com/faq", "source_class": "public_primary", "edition": "live page as read 2026-09-19", "section": "recurring payment questions" } ] }, { "uid": "blik:rule.recurring-consent-in-banking-app", "name": "Recurring payment: consent started at the merchant, confirmed in the bank app", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Polski Standard Płatności S.A. (PSP) itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "blik:src.blik-recurring-payments-introduction", "name": "BLIK Recurring Payments: Introduction", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "Recurring Payment and Recurring Transaction" }, { "uid": "blik:src.blik-recurring-payments-model-a", "name": "BLIK Recurring Payments: Model A", "url": "https://www.blik.com/lp/reccuring-payments/Model-A.141951045.html", "source_class": "authoritative_primary", "edition": "undated live page as read 2026-09-19", "section": "how it works; information displayed in the banking app" }, { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "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", "section": "§2 (definition of Akceptant a, second indent)" } ] } ], "inherited": [ { "facet": "refund", "label": "Refund", "question": "Can the payer get the money back, and on what right?", "fact_uid": "blik:refund", "fact_name": "How does a merchant refund a BLIK payment?" } ], "differs": [ { "facet": "finality", "label": "Finality", "fact_uid": "blik:finality", "fact_name": "When is a BLIK payment final, and can it be undone?", "rules": [ { "uid": "blik:rule.order-entry-and-irrevocable-authorisation", "name": "When a BLIK order is in and when it can no longer be withdrawn" }, { "uid": "blik:rule.settlement-order-irrevocable", "name": "The settlement order is entered and fixed at positive authorisation" }, { "uid": "blik:rule.cancellation-or-correction-13-months", "name": "Cancellation or correction within 13 months" } ] }, { "facet": "settlement", "label": "Settlement", "fact_uid": "blik:settlement", "fact_name": "How and when do BLIK participants settle with each other?", "rules": [ { "uid": "blik:rule.net-clearing", "name": "Net clearing of BLIK transactions, fees included" }, { "uid": "blik:rule.sorbnet3-settlement-run", "name": "Settlement in SORBNET3 through PSP's auxiliary account" }, { "uid": "blik:rule.sessions-single-session-edition", "name": "Clearing sessions, single-session model" }, { "uid": "blik:rule.sessions-multi-session-edition", "name": "Clearing and settlement sessions, multi-session model" }, { "uid": "blik:rule.settlement-guarantee", "name": "Settlement guarantee among issuers" }, { "uid": "blik:rule.settlement-entity", "name": "Every participant settles through a settlement entity" } ] }, { "facet": "hours", "label": "Hours", "fact_uid": "blik:hours", "fact_name": "When can BLIK be used, and how long do codes and approvals last?", "rules": [ { "uid": "blik:rule.continuous-operation", "name": "The scheme runs around the clock" }, { "uid": "blik:rule.one-time-code-validity", "name": "How long a one-time BLIK code lives" } ] }, { "facet": "limits", "label": "Limits", "fact_uid": "blik:limits", "fact_name": "What amount limits apply to a BLIK payment?", "rules": [ { "uid": "blik:rule.per-transaction-limit-unpublished", "name": "Scheme per-transaction limit: set, but not public" }, { "uid": "blik:rule.issuer-set-limits", "name": "Each bank sets its users' BLIK limits" }, { "uid": "blik:rule.psp-fraud-and-gambling-rejection", "name": "PSP rejects on fraud monitoring and blocks illegal gambling domains" } ] }, { "facet": "return", "label": "Return", "fact_uid": "blik:return", "fact_name": "Can a BLIK payment be sent back?", "rules": [ { "uid": "blik:rule.declined-authorisation-never-settles", "name": "A declined transaction never settles" }, { "uid": "blik:rule.complaint-ticket-process", "name": "Complaints run from participant to PSP through a ticket system" } ] }, { "facet": "recall", "label": "Recall", "fact_uid": "blik:recall", "fact_name": "Can a BLIK payment be cancelled or recalled after it is sent?", "rules": [ { "uid": "blik:rule.order-entry-and-irrevocable-authorisation", "name": "When a BLIK order is in and when it can no longer be withdrawn" }, { "uid": "blik:rule.cancellation-or-correction-13-months", "name": "Cancellation or correction within 13 months" } ] }, { "facet": "refund", "label": "Refund", "fact_uid": "blik:refund", "fact_name": "How does a merchant refund a BLIK payment?", "rules": [ { "uid": "blik:rule.disputes-over-goods-outside-scheme", "name": "Goods and services disputes stay between user and merchant" }, { "uid": "blik:rule.user-complains-to-own-bank", "name": "Users complain to their own bank" } ] }, { "facet": "liability", "label": "Liability", "fact_uid": "blik:liability", "fact_name": "Who bears the loss on a BLIK payment that goes wrong?", "rules": [ { "uid": "blik:rule.bad-faith-and-crime-liability", "name": "Who answers for bad-faith, criminal or intruder transactions" }, { "uid": "blik:rule.complaint-fault-pays", "name": "In a complaint the party at fault pays, PSP decides doubt, silence means fault" }, { "uid": "blik:rule.disputes-over-goods-outside-scheme", "name": "Goods and services disputes stay between user and merchant" }, { "uid": "blik:rule.unauthorised-transaction-reporting", "name": "Issuers report unauthorised transactions within two business days" }, { "uid": "blik:rule.complaint-alert-threshold", "name": "Alert when complaints pass 3 percent" }, { "uid": "blik:rule.settlement-guarantee", "name": "Settlement guarantee among issuers" } ] }, { "facet": "consumer-law", "label": "Consumer law", "fact_uid": "blik:consumer-law", "fact_name": "How does BLIK relate to consumer protection law?", "rules": [ { "uid": "blik:rule.issuer-is-users-payment-service-provider", "name": "The issuer is the user's payment service provider" }, { "uid": "blik:rule.user-complains-to-own-bank", "name": "Users complain to their own bank" }, { "uid": "blik:rule.recurring-consent-in-banking-app", "name": "Recurring payment: consent started at the merchant, confirmed in the bank app" }, { "uid": "blik:rule.recurring-cancel-in-banking-app", "name": "Recurring payment: the user sees and cancels it in the bank app" } ] }, { "facet": "messages", "label": "Messages", "fact_uid": "blik:messages", "fact_name": "Which messages carry a BLIK payment and its outcome?", "rules": [ { "uid": "blik:rule.authorisation-flows", "name": "Four ways a BLIK authorisation travels" }, { "uid": "blik:rule.message-standards-technical-specification", "name": "Message formats and error codes live in the Technical Specification" }, { "uid": "blik:rule.recurring-models", "name": "Recurring payment models A, M and O" }, { "uid": "blik:rule.recurring-flags", "name": "Recurring payment flags and the one public BLIK error code" } ] }, { "facet": "participants", "label": "Participants", "fact_uid": "blik:participants", "fact_name": "Who takes part in BLIK, and in what roles?", "rules": [ { "uid": "blik:rule.participant-duties", "name": "What issuers and acquirers must do" } ] }, { "facet": "decision-points", "label": "Human decision points", "fact_uid": "blik:decision-points", "fact_name": "Where do BLIK's rules leave a decision to a person or an institution?", "rules": [ { "uid": "blik:rule.issuer-decides-authorisation", "name": "The issuer decides; an acquirer's no-confirmation hint is only advice" }, { "uid": "blik:rule.psp-fraud-and-gambling-rejection", "name": "PSP rejects on fraud monitoring and blocks illegal gambling domains" }, { "uid": "blik:rule.complaint-fault-pays", "name": "In a complaint the party at fault pays, PSP decides doubt, silence means fault" }, { "uid": "blik:rule.temporary-block", "name": "PSP may block a participant temporarily" }, { "uid": "blik:rule.recurring-retry-72-hours", "name": "Recurring transaction short of funds: 72 hours of bank retries" } ] } ], "exceptions": [ { "uid": "blik:exc.cancellation-correction", "name": "Cancellation or correction", "shared": true, "via": [ { "from": "blik:rule.cancellation-or-correction-13-months", "type": "part_of" } ] }, { "uid": "blik:exc.complaint", "name": "Complaint (reklamacja)", "shared": true, "via": [ { "from": "blik:mandate.recurring-payment", "type": "disputed_via" }, { "from": "blik:rule.complaint-fault-pays", "type": "part_of" }, { "from": "blik:rule.complaint-ticket-process", "type": "part_of" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "part_of" } ] }, { "uid": "blik:exc.decline", "name": "Decline or rejection", "shared": true, "via": [ { "from": "blik:rule.declined-authorisation-never-settles", "type": "part_of" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "part_of" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "part_of" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "part_of" }, { "from": "blik:rule.recurring-flags", "type": "part_of" }, { "from": "blik:rule.recurring-retry-72-hours", "type": "part_of" } ] } ] }, { "uid": "in-upi:txn.recurring", "id": "txn.recurring", "slug": "recurring", "rail": "in-upi", "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "page": "in-upi/recurring.html", "file": "data/products/in-upi/recurring.json", "name": "Recurring UPI payment taken under a mandate", "anchor": "an authorisation of its own, a lifecycle of its own (5 states)", "transaction_type": { "uid": "in-upi:txn.recurring", "name": "Recurring UPI payment taken under a mandate", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "effective_since": "2026-04-21", "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", "directions": [ "debit" ], "account_types": [ "any" ], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 2" }, { "uid": "in-upi:src.rbi-authentication-directions-2025", "name": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898&Mode=0", "source_class": "authoritative_primary", "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", "section": "Annexure-1, item 2" } ] }, "counts": { "rules": 16, "mandates": 1, "states": 5, "code_sets": 0, "reason_codes": 0, "roles": 5, "members": 23 }, "trust": { "members": 23, "by_status": { "draft": 2, "corroborated": 21, "verified": 0, "superseded": 0 }, "strongest_source_class": "authoritative_primary" }, "roles": [ { "uid": "in-upi:role.customer", "name": "Customer (the payer)", "kind": "party", "via": [ "given_by" ] }, { "uid": "in-upi:role.merchant", "name": "Merchant (the payee in a payment for goods or services)", "kind": "party", "via": [ "given_to", "binds" ] }, { "uid": "in-upi:role.payment-system-participant", "name": "Payment System Participant (a member of an authorised payment system)", "kind": "institution", "via": [ "binds" ] }, { "uid": "in-upi:role.remitter-bank", "name": "Remitter bank (the payer's bank)", "kind": "institution", "via": [ "binds" ] }, { "uid": "in-upi:role.third-party-app-provider", "name": "Third party application provider (TPAP)", "kind": "service_provider", "via": [ "binds" ] } ], "mandates": [ { "uid": "in-upi:mandate.upi-recurring", "name": "UPI recurring payment mandate", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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" ], "constraints": null, "governed_by": [ { "uid": "in-upi:rule.e-mandate-framework-covers-upi", "name": "The recurring payment framework covers UPI" }, { "uid": "in-upi:rule.e-mandate-first-charge", "name": "The first charge under a mandate is authenticated" }, { "uid": "in-upi:rule.e-mandate-notice-before-each-charge", "name": "The customer is told at least a day before each recurring charge" }, { "uid": "in-upi:rule.e-mandate-notice-after-each-charge", "name": "The customer is told after each recurring charge" }, { "uid": "in-upi:rule.e-mandate-authentication-threshold", "name": "Recurring payments up to 15,000 rupees need no fresh authentication" }, { "uid": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "name": "Three kinds of recurring payment have a 1,00,000 rupee threshold instead" }, { "uid": "in-upi:rule.e-mandate-costs-the-customer-nothing", "name": "A recurring mandate costs the customer nothing, and the acquirer answers for its merchants" } ], "revoked_via": [ { "uid": "in-upi:rule.e-mandate-registration-and-withdrawal", "name": "Registering a recurring mandate, and getting out of one" }, { "uid": "in-upi:rule.upi-autopay-revocation", "name": "UPI AutoPay: revoking a mandate, from either side" } ], "evidenced_by": [ { "uid": "in-upi:rule.e-mandate-registration-and-withdrawal", "name": "Registering a recurring mandate, and getting out of one" } ], "disputed_via": [ { "uid": "in-upi:exc.unauthorised-transaction-claim", "name": "Claim that the customer did not authorise the payment", "shared": true } ], "given_by": [ { "uid": "in-upi:role.customer", "name": "Customer (the payer)", "note": null } ], "given_to": [ { "uid": "in-upi:role.merchant", "name": "Merchant (the payee in a payment for goods or services)", "note": null } ], "sources": [] } ], "states": [ { "uid": "in-upi:state.e-mandate-registered", "name": "UPI recurring e-mandate: registered", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [ { "uid": "in-upi:state.e-mandate-withdrawn", "name": "UPI recurring e-mandate: withdrawn by the customer" }, { "uid": "in-upi:state.upi-autopay-paused", "name": "UPI AutoPay mandate: paused" }, { "uid": "in-upi:state.upi-autopay-revoked", "name": "UPI AutoPay mandate: revoked" }, { "uid": "in-upi:state.upi-autopay-expired", "name": "UPI AutoPay mandate: expired" } ], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraphs 2, 4(a) to (c), 5(a) and 6(a)" }, { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.3, 14.5, 14.16 to 14.19, 14.24.6 and 14.24.7" } ] }, { "uid": "in-upi:state.e-mandate-withdrawn", "name": "UPI recurring e-mandate: withdrawn by the customer", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraphs 4(b), 4(e) and 6(c)" } ] }, { "uid": "in-upi:state.upi-autopay-paused", "name": "UPI AutoPay mandate: paused", "status": "draft", "stored_status": "draft", "source_class": null, "confidence": "medium", "tier": { "k": "draft", "label": "Draft, unchecked", "say": "An agent wrote this from published material and nobody has checked it. Treat it as a lead to confirm, not an answer, before acting on any retry, deadline or rate." }, "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, "precedes": [ { "uid": "in-upi:state.e-mandate-registered", "name": "UPI recurring e-mandate: registered" }, { "uid": "in-upi:state.upi-autopay-revoked", "name": "UPI AutoPay mandate: revoked" }, { "uid": "in-upi:state.upi-autopay-expired", "name": "UPI AutoPay mandate: expired" } ], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.3, 14.18 to 14.20 and 33.4" } ] }, { "uid": "in-upi:state.upi-autopay-expired", "name": "UPI AutoPay mandate: expired", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.3, 14.5 and 14.16; Annexure A, Mandate Validity Period" } ] }, { "uid": "in-upi:state.upi-autopay-revoked", "name": "UPI AutoPay mandate: revoked", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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, "precedes": [], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.3, 14.18, 14.19, 14.21 to 14.23 and 33.4" } ] } ], "code_sets": [], "reason_codes": [], "rules": [ { "uid": "in-upi:rule.e-mandate-authentication-threshold", "name": "Recurring payments up to 15,000 rupees need no fresh authentication", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "limit", "text": "15,000 rupees per recurring transaction without an additional factor of authentication" } ], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 8(a)" } ] }, { "uid": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "name": "Three kinds of recurring payment have a 1,00,000 rupee threshold instead", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "limit", "text": "1,00,000 rupees per transaction for insurance premiums, mutual fund subscriptions and credit card bill payments" } ], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 8(b)" } ] }, { "uid": "in-upi:rule.upi-autopay-validity-and-expiry", "name": "UPI AutoPay: a mandate lasts at most 30 years and lapses at its end date", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.5 and 14.16; Annexure A, Mandate Validity Period" } ] }, { "uid": "in-upi:rule.upi-autopay-pause-and-unpause", "name": "UPI AutoPay: pausing a mandate and lifting the pause", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "recall", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.18, 14.19, 14.20 and 33.4" } ] }, { "uid": "in-upi:rule.upi-autopay-revocation", "name": "UPI AutoPay: revoking a mandate, from either side", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "recall", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.18, 14.19, 14.21, 14.22, 14.23 and 33.4" } ] }, { "uid": "in-upi:rule.e-mandate-disputes-and-liability", "name": "Disputes on a recurring payment, and who bears an unauthorised one", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [ "in-upi:exc.unauthorised-transaction-claim" ], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 9" }, { "uid": "in-upi:src.rbi-customer-liability-circular-2017", "name": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15)", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11040&Mode=0", "source_class": "authoritative_primary", "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", "section": "paragraphs 6 to 9" } ] }, { "uid": "in-upi:rule.e-mandate-costs-the-customer-nothing", "name": "A recurring mandate costs the customer nothing, and the acquirer answers for its merchants", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 10" } ] }, { "uid": "in-upi:rule.e-mandate-first-charge", "name": "The first charge under a mandate is authenticated", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 5" } ] }, { "uid": "in-upi:rule.e-mandate-notice-after-each-charge", "name": "The customer is told after each recurring charge", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 7" } ] }, { "uid": "in-upi:rule.e-mandate-notice-before-each-charge", "name": "The customer is told at least a day before each recurring charge", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 6" } ] }, { "uid": "in-upi:rule.e-mandate-registration-and-withdrawal", "name": "Registering a recurring mandate, and getting out of one", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraph 4" } ] }, { "uid": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "name": "UPI AutoPay: the customer hears about every change to a mandate, twice", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "section 14.3" } ] }, { "uid": "in-upi:rule.upi-autopay-modification", "name": "UPI AutoPay: changing a live mandate's amount or payee", "status": "draft", "stored_status": "draft", "source_class": null, "confidence": "medium", "tier": { "k": "draft", "label": "Draft, unchecked", "say": "An agent wrote this from published material and nobody has checked it. Treat it as a lead to confirm, not an answer, before acting on any retry, deadline or rate." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "section": "sections 14.16, 14.17, 14.24.6 and 14.24.7" } ] }, { "uid": "in-upi:rule.e-mandate-framework-covers-upi", "name": "The recurring payment framework covers UPI", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "participants", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "name": "RBI Digital Payments E-mandate Framework, 2026", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "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", "section": "paragraphs 1 and 2" } ] }, { "uid": "in-upi:rule.authentication-exemptions-include-upi-tap-and-pay", "name": "Which payments are exempt from two factor authentication, including a UPI tap and pay", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "in-upi:txn.merchant-payment", "name": "UPI payment to a merchant" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-authentication-directions-2025", "name": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898&Mode=0", "source_class": "authoritative_primary", "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", "section": "Annexure-1, items 1 to 7, in particular items 2 and 7" } ] }, { "uid": "in-upi:rule.two-factors-of-authentication", "name": "A digital payment is authenticated with at least two distinct factors", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Reserve Bank of India itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "in-upi:txn.funds-transfer", "name": "UPI transfer of funds to another person" }, { "uid": "in-upi:txn.merchant-payment", "name": "UPI payment to a merchant" }, { "uid": "in-upi:txn.123pay", "name": "UPI 123Pay, a UPI payment from a feature phone" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "in-upi:src.rbi-authentication-directions-2025", "name": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898&Mode=0", "source_class": "authoritative_primary", "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", "section": "paragraphs 5, 6(a), 6(b) and 6(c)" } ] } ], "inherited": [ { "facet": "finality", "label": "Finality", "question": "When is a payment final, and can it be undone?", "fact_uid": "in-upi:finality", "fact_name": "When does a UPI payment become final?" }, { "facet": "settlement", "label": "Settlement", "question": "How and when does the money settle between institutions?", "fact_uid": "in-upi:settlement", "fact_name": "How and when do UPI positions settle?" }, { "facet": "hours", "label": "Hours", "question": "When does the rail run, and what are its cut-offs?", "fact_uid": "in-upi:hours", "fact_name": "When is UPI open?" }, { "facet": "return", "label": "Return", "question": "How does a payment come back, and on what deadline?", "fact_uid": "in-upi:return", "fact_name": "What happens when a UPI payment does not reach the payee?" }, { "facet": "refund", "label": "Refund", "question": "Can the payer get the money back, and on what right?", "fact_uid": "in-upi:refund", "fact_name": "How does a UPI refund work?" }, { "facet": "messages", "label": "Messages", "question": "What messages carry the payment and the answers to it?", "fact_uid": "in-upi:messages", "fact_name": "What message standard does UPI use, and what codes does it carry?" }, { "facet": "decision-points", "label": "Human decision points", "question": "Where does a rule leave the decision to a bank or a person?", "fact_uid": "in-upi:decision-points", "fact_name": "Where does a rule leave the decision to a bank or a person?" } ], "differs": [ { "facet": "limits", "label": "Limits", "fact_uid": "in-upi:limits", "fact_name": "What limits apply to a UPI payment?", "rules": [ { "uid": "in-upi:rule.e-mandate-authentication-threshold", "name": "Recurring payments up to 15,000 rupees need no fresh authentication" }, { "uid": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "name": "Three kinds of recurring payment have a 1,00,000 rupee threshold instead" } ] }, { "facet": "recall", "label": "Recall", "fact_uid": "in-upi:recall", "fact_name": "Can a UPI payment be cancelled or recalled after it is sent?", "rules": [ { "uid": "in-upi:rule.e-mandate-registration-and-withdrawal", "name": "Registering a recurring mandate, and getting out of one" }, { "uid": "in-upi:rule.e-mandate-notice-before-each-charge", "name": "The customer is told at least a day before each recurring charge" } ] }, { "facet": "liability", "label": "Liability", "fact_uid": "in-upi:liability", "fact_name": "Who bears the loss on a UPI payment?", "rules": [ { "uid": "in-upi:rule.e-mandate-disputes-and-liability", "name": "Disputes on a recurring payment, and who bears an unauthorised one" } ] }, { "facet": "consumer-law", "label": "Consumer law", "fact_uid": "in-upi:consumer-law", "fact_name": "What protection does a UPI customer have, and where do they go?", "rules": [ { "uid": "in-upi:rule.two-factors-of-authentication", "name": "A digital payment is authenticated with at least two distinct factors" }, { "uid": "in-upi:rule.authentication-exemptions-include-upi-tap-and-pay", "name": "Which payments are exempt from two factor authentication, including a UPI tap and pay" }, { "uid": "in-upi:rule.e-mandate-registration-and-withdrawal", "name": "Registering a recurring mandate, and getting out of one" }, { "uid": "in-upi:rule.e-mandate-notice-before-each-charge", "name": "The customer is told at least a day before each recurring charge" }, { "uid": "in-upi:rule.e-mandate-notice-after-each-charge", "name": "The customer is told after each recurring charge" }, { "uid": "in-upi:rule.e-mandate-first-charge", "name": "The first charge under a mandate is authenticated" }, { "uid": "in-upi:rule.e-mandate-costs-the-customer-nothing", "name": "A recurring mandate costs the customer nothing, and the acquirer answers for its merchants" } ] }, { "facet": "participants", "label": "Participants", "fact_uid": "in-upi:participants", "fact_name": "Who takes part in UPI, and who lets them?", "rules": [ { "uid": "in-upi:rule.e-mandate-framework-covers-upi", "name": "The recurring payment framework covers UPI" } ] } ], "exceptions": [ { "uid": "in-upi:exc.unauthorised-transaction-claim", "name": "Claim that the customer did not authorise the payment", "shared": true, "via": [ { "from": "in-upi:mandate.upi-recurring", "type": "disputed_via" }, { "from": "in-upi:rule.e-mandate-disputes-and-liability", "type": "part_of" } ] } ] }, { "uid": "pix:txn.pix-automatico", "id": "txn.pix-automatico", "slug": "pix-automatico", "rail": "pix", "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "page": "pix/pix-automatico.html", "file": "data/products/pix/pix-automatico.json", "name": "Pix Automatico", "anchor": "an authorisation of its own, a lifecycle of its own (5 states), 3 code sets of its own", "transaction_type": { "uid": "pix:txn.pix-automatico", "name": "Pix Automatico", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "effective_since": "2025-06-16", "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", "directions": [ "credit" ], "account_types": [ "any" ], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "arts. 11-Q to 11-V" }, { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "arts. 5 to 7 and 17 II" } ] }, "counts": { "rules": 28, "mandates": 1, "states": 5, "code_sets": 3, "reason_codes": 0, "roles": 4, "members": 38 }, "trust": { "members": 38, "by_status": { "draft": 1, "corroborated": 37, "verified": 0, "superseded": 0 }, "strongest_source_class": "authoritative_primary" }, "roles": [ { "uid": "pix:role.payer", "name": "Usuario pagador", "kind": "party", "via": [ "given_by" ] }, { "uid": "pix:role.payer-psp", "name": "PSP do pagador", "kind": "institution", "via": [ "given_to", "binds" ] }, { "uid": "pix:role.receiver-psp", "name": "PSP do recebedor", "kind": "institution", "via": [ "binds" ] }, { "uid": "pix:role.receiving-user", "name": "Usuario recebedor", "kind": "party", "via": [ "given_to" ] } ], "mandates": [ { "uid": "pix:mandate.pix-automatico-authorisation", "name": "Pix Automatico authorisation", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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." } }, "governed_by": [ { "uid": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "name": "Pix Automatico: one authorisation, then collections the payer's bank pushes" }, { "uid": "pix:rule.automatico-four-journeys-to-an-authorisation", "name": "Pix Automatico: the four ways an authorisation is given" }, { "uid": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "name": "Pix Automatico: a journey 1 request stays open for at most 30 days" }, { "uid": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "name": "Pix Automatico: in journey 3 the first payment is a condition of the authorisation" }, { "uid": "pix:rule.automatico-what-an-authorisation-must-state", "name": "Pix Automatico: the parameters every authorisation carries" }, { "uid": "pix:rule.automatico-five-recurrence-periods", "name": "Pix Automatico: weekly, monthly, quarterly, half-yearly or yearly, and one charge per cycle" }, { "uid": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "name": "Pix Automatico: when a cycle's day does not exist in the month" }, { "uid": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "name": "Pix Automatico: who fixes the ceiling on a variable authorisation" }, { "uid": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "name": "Pix Automatico: what the payer may change on a live authorisation" }, { "uid": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "name": "Pix Automatico: a pre-approved credit line may pay what the balance cannot" }, { "uid": "pix:rule.automatico-who-may-offer-and-who-may-collect", "name": "Pix Automatico: every account provider offers it to payers, and only established businesses may collect" }, { "uid": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "name": "Pix Automatico: when a collection instruction may be sent" }, { "uid": "pix:rule.automatico-settlement-date-is-the-due-date", "name": "Pix Automatico: the settlement date is the due date, and payments run on any day" }, { "uid": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "name": "Pix Automatico: the payer's bank schedules within two hours or refuses" }, { "uid": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "name": "Pix Automatico: the settlement window on the day and the same day retry" }, { "uid": "pix:rule.automatico-retries-on-later-days", "name": "Pix Automatico: retries on later days, at most 3 within 7 days" }, { "uid": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "name": "Pix Automatico: resending after an error in the settlement flow" }, { "uid": "pix:rule.automatico-cancelling-one-scheduled-payment", "name": "Pix Automatico: calling off one scheduled payment" }, { "uid": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "name": "Pix Automatico: the three places a collection can be refused, and who refuses" }, { "uid": "pix:rule.messages-pix-automatico-authorization-messages", "name": "Pix Automatico: authorization messages" }, { "uid": "pix:rule.messages-pix-automatico-instruction-messages", "name": "Pix Automatico: instruction messages" }, { "uid": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "name": "The user can drive the limit in both directions" } ], "revoked_via": [ { "uid": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "name": "Pix Automatico: cancelling the authorisation, and the recorded reasons" }, { "uid": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "name": "Pix Automatico: what a cancellation does to payments already scheduled" } ], "evidenced_by": [], "disputed_via": [ { "uid": "pix:exc.med", "name": "Mecanismo Especial de Devolucao and Recuperacao de Valores", "shared": true } ], "given_by": [ { "uid": "pix:role.payer", "name": "Usuario pagador", "note": null } ], "given_to": [ { "uid": "pix:role.payer-psp", "name": "PSP do pagador", "note": "Regulamento art. 11-Q par. 1 inciso I: the authorisation is given to the payer's own bank." }, { "uid": "pix:role.receiving-user", "name": "Usuario recebedor", "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." } ], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "arts. 11-Q to 11-V" }, { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "arts. 2 to 11 and 15-A" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "sections 2.4.3 and 2.8, Annex I section 5.1, Annex IV sections 2 and 4" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15" } ] } ], "states": [ { "uid": "pix:state.recurrence-created", "name": "Pix Automatico recurrence: created", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [ { "uid": "pix:state.recurrence-approved", "name": "Pix Automatico recurrence: approved by the payer" }, { "uid": "pix:state.recurrence-rejected", "name": "Pix Automatico recurrence: rejected" }, { "uid": "pix:state.recurrence-cancelled", "name": "Pix Automatico recurrence: cancelled" } ], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6" } ] }, { "uid": "pix:state.recurrence-approved", "name": "Pix Automatico recurrence: approved by the payer", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [ { "uid": "pix:state.recurrence-expired", "name": "Pix Automatico recurrence: expired" }, { "uid": "pix:state.recurrence-cancelled", "name": "Pix Automatico recurrence: cancelled" } ], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6" } ] }, { "uid": "pix:state.recurrence-cancelled", "name": "Pix Automatico recurrence: cancelled", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 item 27" } ] }, { "uid": "pix:state.recurrence-expired", "name": "Pix Automatico recurrence: expired", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6" } ] }, { "uid": "pix:state.recurrence-rejected", "name": "Pix Automatico recurrence: rejected", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6" } ] } ], "code_sets": [ { "uid": "pix:codeset.pain011-cancellation-reasons", "name": "Pix Automatico cancellation reasons (pain.011)", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "owner": "Banco Central do Brasil", "complete": true, "values": [ { "code": "ACCL", "name": "the payer's or the business's account was closed" }, { "code": "CPCL", "name": "the business has shut down" }, { "code": "DCSD", "name": "the payer has died" }, { "code": "ERSL", "name": "the business or its bank withdrew a pending request that contained an error" }, { "code": "FRUD", "name": "suspected fraud" }, { "code": "NRES", "name": "the business's bank withdrew a pending request the payer's bank never acknowledged in time" }, { "code": "OTHS", "name": "any other reason; only where no other code fits" }, { "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" }, { "code": "SJUD", "name": "a court order" }, { "code": "SLCR", "name": "the business asked for it" }, { "code": "SLDB", "name": "the payer asked for it" } ], "sources": [ { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN011.xlsx, Tabela de Dominios, CancellationReason Proprietary (MotivoCancelamentoCode), in 5.12.1 and 5.13.1" } ] }, { "uid": "pix:codeset.pain012-authorisation-rejection-reasons", "name": "Pix Automatico authorisation rejection reasons (pain.012)", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "owner": "Banco Central do Brasil", "complete": true, "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" } ], "sources": [ { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN012.xlsx, Tabela de Dominios, RejectReason Proprietary (MotivoRejeicaoCode), in 5.12.1 and 5.13.1" } ] }, { "uid": "pix:codeset.pain014-instruction-errors", "name": "Pix Automatico instruction errors (pain.014)", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "owner": "Banco Central do Brasil", "complete": true, "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" } ], "sources": [ { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN014.xlsx, Tabela de Dominios, StatusReasonInformation Reason Proprietary (CodigoDeErroPain014Code), in 5.12.1 and 5.13.1" } ] } ], "reason_codes": [], "rules": [ { "uid": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "name": "Pix Automatico: when a cycle's day does not exist in the month", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex IV section 4.3.1 and its footnote 105" } ] }, { "uid": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "name": "Pix Automatico: resending after an error in the settlement flow", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "arts. 5 par. 4 and 7 paragraphs 11 to 16" } ] }, { "uid": "pix:rule.automatico-five-recurrence-periods", "name": "Pix Automatico: weekly, monthly, quarterly, half-yearly or yearly, and one charge per cycle", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "arts. 2 and 5 par. 3" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex IV section 4.3.1" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN011.xlsx and PAIN012.xlsx domain tables, Frequency Type" } ] }, { "uid": "pix:rule.automatico-settlement-date-is-the-due-date", "name": "Pix Automatico: the settlement date is the due date, and payments run on any day", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 5 paragraphs 5 and 6" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 item 04" } ] }, { "uid": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "name": "Pix Automatico: a journey 1 request stays open for at most 30 days", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "time_window", "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" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 3 caput and paragraphs 1 and 2" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 06 and 09" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN012.xlsx domain table, RejectReason" } ] }, { "uid": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "name": "Pix Automatico: when a collection instruction may be sent", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "time_window", "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" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 5 paragraphs 1, 2, 7, 8 and 10" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN014.xlsx domain table, FCD1 and FCD2" } ] }, { "uid": "pix:rule.automatico-retries-on-later-days", "name": "Pix Automatico: retries on later days, at most 3 within 7 days", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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).", "facet": "hours", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "time_window", "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" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 7 paragraphs 5 to 10" }, { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-U inciso VI" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex IV section 2.1.5" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN014.xlsx domain table, IRNT, QUNT and DTNT" } ] }, { "uid": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "name": "Pix Automatico: the settlement window on the day and the same day retry", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "time_window", "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" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 7 caput and paragraphs 1 to 4" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 04, 48 and 49" } ] }, { "uid": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "name": "Pix Automatico: a pre-approved credit line may pay what the balance cannot", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-U inciso V alinea c" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 02, 04, 28 and 29" } ] }, { "uid": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "name": "Pix Automatico: who fixes the ceiling on a variable authorisation", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-U inciso V alinea b" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 16, 28, 53 and 58" }, { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 6 par. 1 incisos I and II" } ] }, { "uid": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "name": "The user can drive the limit in both directions", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "mandate", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-512-2024-limites", "name": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instrução%20Normativa%20BCB&numero=512", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 4, amendments listed through Instrucao Normativa BCB n. 746 de 18/6/2026", "section": "arts. 10 caput and par. 2 (incisos as amended by IN BCB n. 629 de 5/6/2025) and 3 par. 14" } ] }, { "uid": "pix:rule.automatico-cancelling-one-scheduled-payment", "name": "Pix Automatico: calling off one scheduled payment", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "recall", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "time_window", "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" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 8" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 32 and 34" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex IV section 4.3.2" } ] }, { "uid": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "name": "Pix Automatico: what a cancellation does to payments already scheduled", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "recall", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 9 caput and paragraphs 1, 2 and 3" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 27 and 52" } ] }, { "uid": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "name": "Pix Automatico: cancelling the authorisation, and the recorded reasons", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "recall", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-Q par. 1 incisos IV and V" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex V section 3.3 and Annex IV section 2.1.6" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN011.xlsx domain table, CancellationReason Proprietary" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 item 27" } ] }, { "uid": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "name": "Pix Automatico: the payer's bank refunds a faulty payment within 24 hours", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "refund", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [ { "kind": "time_window", "text": "full refund to the payer, from the bank's own funds, within 24 hours of the payer's request" } ], "part_of": [ "pix:exc.med" ], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 15" } ] }, { "uid": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "name": "Pix Automatico: the payer's bank schedules within two hours or refuses", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [ { "kind": "time_window", "text": "schedule, or refuse, within two hours of receiving the payment instruction" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 6 caput and paragraphs 1 and 2" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN014.xlsx domain table, StatusReasonInformation" } ] }, { "uid": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "name": "Pix Automatico: the payer's bank pays first", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "liability", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [ "pix:exc.med" ], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "arts. 41-A par. 2 incisos I and II and 11-V" } ] }, { "uid": "pix:rule.automatico-what-an-authorisation-must-state", "name": "Pix Automatico: the parameters every authorisation carries", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-U caput inciso V alineas a to f" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 16 and 25" } ] }, { "uid": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "name": "Pix Automatico: what the payer may change on a live authorisation", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "consumer-law", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-Q par. 1 inciso IV and par. 3" }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 25, 28, 29, 30 and 31" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex IV section 4.2.1" } ] }, { "uid": "pix:rule.automatico-the-pacs008-is-marked-auto", "name": "Pix Automatico: how the settlement message identifies it", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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).", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 7 paragraphs 17 and 18" } ] }, { "uid": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "name": "Pix Automatico: the three places a collection can be refused, and who refuses", "status": "draft", "stored_status": "draft", "source_class": null, "confidence": "high", "tier": { "k": "draft", "label": "Draft, unchecked", "say": "An agent wrote this from published material and nobody has checked it. Treat it as a lead to confirm, not an answer, before acting on any retry, deadline or rate." }, "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).", "facet": "messages", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN012.xlsx and PAIN014.xlsx domain tables in 5.12.1 and 5.13.1" }, { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "arts. 6 par. 1 and 7 par. 1" } ] }, { "uid": "pix:rule.cobranca-static-dynamic-and-composite-qr-codes", "name": "Pix QR codes: static, dynamic and composite", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "pix:txn.pix-cobranca", "name": "Pix Cobranca" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "sections 2.4, 2.6, 2.7, 2.7.2 and 2.8, and footnote 87" } ] }, { "uid": "pix:rule.messages-pix-automatico-authorization-messages", "name": "Pix Automatico: authorization messages", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "name": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/Catalogo_de_Servicos_do_SFN_Volume_VI_Versao_512.pdf", "source_class": "authoritative_primary", "edition": "versao 5.12, dated 2026-03-27, in SPI production from 2026-06-28", "section": "p. 19" } ] }, { "uid": "pix:rule.messages-pix-automatico-instruction-messages", "name": "Pix Automatico: instruction messages", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "name": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/Catalogo_de_Servicos_do_SFN_Volume_VI_Versao_512.pdf", "source_class": "authoritative_primary", "edition": "versao 5.12, dated 2026-03-27, in SPI production from 2026-06-28", "section": "p. 20" } ] }, { "uid": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "name": "Pix Automatico: one authorisation, then collections the payer's bank pushes", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "participants", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-Q caput, par. 1 incisos I, II, III and VI, and par. 2" } ] }, { "uid": "pix:rule.automatico-four-journeys-to-an-authorisation", "name": "Pix Automatico: the four ways an authorisation is given", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "participants", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "arts. 11-Q par. 1 incisos VII and VIII, 11-S par. 3 and 11-T par. 6" }, { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 4" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "sections 2.4.3, 2.8 and 6.3, and Annex IV section 2.1.7" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN012.xlsx domain table, MandateProcessingType" } ] }, { "uid": "pix:rule.automatico-who-may-offer-and-who-may-collect", "name": "Pix Automatico: every account provider offers it to payers, and only established businesses may collect", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 3 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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).", "facet": "participants", "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "arts. 11-S caput and paragraphs 1 and 3, and 11-T caput and paragraphs 1, 2, 3 and 7" }, { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "art. 15-A" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN012.xlsx domain table, RejectReason AP15 and SA01" } ] }, { "uid": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "name": "Pix Automatico: in journey 3 the first payment is a condition of the authorisation", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": null, "rests_on": "rule", "via": "both", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "section": "chapter 15 items 20, 22 and 23" }, { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-Q par. 1 incisos I and VII alinea c" }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "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)", "section": "PAIN012.xlsx domain table, RejectReason AP08" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "section 6.3.3" } ] } ], "inherited": [ { "facet": "finality", "label": "Finality", "question": "When is a payment final, and can it be undone?", "fact_uid": "pix:finality", "fact_name": "When does a Pix become final, and can it be reversed?" }, { "facet": "return", "label": "Return", "question": "How does a payment come back, and on what deadline?", "fact_uid": "pix:return", "fact_name": "Can a settled Pix be returned, by whom and by when?" }, { "facet": "decision-points", "label": "Human decision points", "question": "Where does a rule leave the decision to a bank or a person?", "fact_uid": "pix:decision-points", "fact_name": "Where does Pix hand the outcome to a human or a bank's judgment?" } ], "differs": [ { "facet": "limits", "label": "Limits", "fact_uid": "pix:limits", "fact_name": "What limits apply to a Pix, and who sets them?", "rules": [ { "uid": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "name": "The user can drive the limit in both directions" } ] }, { "facet": "refund", "label": "Refund", "fact_uid": "pix:refund", "fact_name": "Does anyone have a right to be refunded, and how does the money get back?", "rules": [ { "uid": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "name": "Pix Automatico: the payer's bank pays first" } ] }, { "facet": "liability", "label": "Liability", "fact_uid": "pix:liability", "fact_name": "Who bears the loss when a Pix goes wrong?", "rules": [ { "uid": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "name": "Pix Automatico: the payer's bank pays first" } ] }, { "facet": "messages", "label": "Messages", "fact_uid": "pix:messages", "fact_name": "What messages carry a Pix, and what is not a message at all?", "rules": [ { "uid": "pix:rule.messages-pix-automatico-authorization-messages", "name": "Pix Automatico: authorization messages" }, { "uid": "pix:rule.messages-pix-automatico-instruction-messages", "name": "Pix Automatico: instruction messages" } ] } ], "exceptions": [ { "uid": "pix:exc.med", "name": "Mecanismo Especial de Devolucao and Recuperacao de Valores", "shared": true, "via": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "disputed_via" }, { "from": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "type": "part_of" }, { "from": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "type": "part_of" } ] } ] }, { "uid": "pix:txn.pix-cobranca", "id": "txn.pix-cobranca", "slug": "pix-cobranca", "rail": "pix", "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "page": "pix/pix-cobranca.html", "file": "data/products/pix/pix-cobranca.json", "name": "Pix Cobranca", "anchor": "a lifecycle of its own (4 states)", "transaction_type": { "uid": "pix:txn.pix-cobranca", "name": "Pix Cobranca", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "effective_since": "2020-11-03", "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", "directions": [ "credit" ], "account_types": [ "any" ], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "arts. 11-A, 11-B, 11-C, 11-D and 11-E" }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "sections 2.4, 2.7 and Annex I section 5.1" } ] }, "counts": { "rules": 8, "mandates": 0, "states": 4, "code_sets": 0, "reason_codes": 0, "roles": 4, "members": 13 }, "trust": { "members": 13, "by_status": { "draft": 0, "corroborated": 13, "verified": 0, "superseded": 0 }, "strongest_source_class": "authoritative_primary" }, "roles": [ { "uid": "pix:role.payer-psp", "name": "PSP do pagador", "kind": "institution", "via": [ "binds" ] }, { "uid": "pix:role.pix-participant", "name": "Participante do Pix", "kind": "institution", "via": [ "binds" ] }, { "uid": "pix:role.receiver-psp", "name": "PSP do recebedor", "kind": "institution", "via": [ "binds" ] }, { "uid": "pix:role.receiving-user", "name": "Usuario recebedor", "kind": "party", "via": [ "binds" ] } ], "mandates": [], "states": [ { "uid": "pix:state.charge-active", "name": "Pix charge: active", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [ { "uid": "pix:state.charge-concluded", "name": "Pix charge: concluded" }, { "uid": "pix:state.charge-removed-by-the-receiver", "name": "Pix charge: removed by the receiver" }, { "uid": "pix:state.charge-removed-by-the-psp", "name": "Pix charge: removed by the payee's bank" } ], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "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" } ] }, { "uid": "pix:state.charge-concluded", "name": "Pix charge: concluded", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "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" } ] }, { "uid": "pix:state.charge-removed-by-the-psp", "name": "Pix charge: removed by the payee's bank", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "low", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "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" } ] }, { "uid": "pix:state.charge-removed-by-the-receiver", "name": "Pix charge: removed by the receiver", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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", "precedes": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "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" } ] } ], "code_sets": [], "reason_codes": [], "rules": [ { "uid": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "name": "Pix Cobranca: one payment per charge, and a transaction identifier used once", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "finality", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "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" } ] }, { "uid": "pix:rule.cobranca-the-payees-bank-computes-the-final-amount", "name": "Pix Cobranca: who computes interest, fines, discounts and rebates", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "settlement", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "sections 2.7.1.2 and Annex III sections 1 and 3" } ] }, { "uid": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "name": "Pix Agendado and scheduled due date charges: the settlement window and the evening retry", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 2 named sources, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "pix:txn.pix-agendado", "name": "Pix Agendado (scheduled Pix)" } ], "parameters": [ { "kind": "time_window", "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" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "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", "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", "section": "arts. 12 and 14" }, { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "art. 11-D par. unico" } ] }, { "uid": "pix:rule.cobranca-a-due-date-charge-rolls-to-the-payers-next-business-day", "name": "Pix Cobranca: due date, grace period and the payer's holidays", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "section 2.7.1.2 with footnotes 41, 44 and 45, and Annex III section 3" } ] }, { "uid": "pix:rule.cobranca-an-immediate-charge-lives-24-hours-by-default", "name": "Pix Cobranca: how long an immediate charge stays payable", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [ { "kind": "time_window", "text": "default life of an immediate charge, from its creation, when the creator sets no expiry" } ], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "sections 2.7.1.1 and 2.7.3" } ] }, { "uid": "pix:rule.cobranca-a-static-code-leaves-reconciliation-to-the-receiver", "name": "Pix QR codes: a static code's identifier is the receiver's to keep consistent", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "Annex I section 5.3.2 and section 2.4.1 footnote 6" } ] }, { "uid": "pix:rule.cobranca-static-dynamic-and-composite-qr-codes", "name": "Pix QR codes: static, dynamic and composite", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "messages", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "pix:txn.pix-automatico", "name": "Pix Automatico" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "section": "sections 2.4, 2.6, 2.7, 2.7.2 and 2.8, and footnote 87" } ] }, { "uid": "pix:rule.cobranca-immediate-and-due-date-charges", "name": "Pix Cobranca: a charge for immediate payment or for payment by a due date", "status": "corroborated", "stored_status": "corroborated", "source_class": "authoritative_primary", "confidence": "high", "tier": { "k": "cor", "label": "Corroborated (authoritative primary)", "say": "A validator compared this with 1 named source, the strongest being a publication of Banco Central do Brasil itself. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "participants", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "section": "arts. 11-A, 11-B, 11-C, 11-D, 11-DA and 11-E" } ] } ], "inherited": [ { "facet": "limits", "label": "Limits", "question": "What limits apply to a payment, and who sets them?", "fact_uid": "pix:limits", "fact_name": "What limits apply to a Pix, and who sets them?" }, { "facet": "return", "label": "Return", "question": "How does a payment come back, and on what deadline?", "fact_uid": "pix:return", "fact_name": "Can a settled Pix be returned, by whom and by when?" }, { "facet": "recall", "label": "Recall", "question": "Can the sender ask for a payment back, and who decides?", "fact_uid": "pix:recall", "fact_name": "Can the payer's side pull a Pix back, and what does asking actually do?" }, { "facet": "refund", "label": "Refund", "question": "Can the payer get the money back, and on what right?", "fact_uid": "pix:refund", "fact_name": "Does anyone have a right to be refunded, and how does the money get back?" }, { "facet": "liability", "label": "Liability", "question": "Who bears a loss when something goes wrong?", "fact_uid": "pix:liability", "fact_name": "Who bears the loss when a Pix goes wrong?" }, { "facet": "consumer-law", "label": "Consumer law", "question": "What does the law give a consumer here, beyond the rulebook?", "fact_uid": "pix:consumer-law", "fact_name": "What protects an end user on Pix, and where does the rulebook stop?" }, { "facet": "decision-points", "label": "Human decision points", "question": "Where does a rule leave the decision to a bank or a person?", "fact_uid": "pix:decision-points", "fact_name": "Where does Pix hand the outcome to a human or a bank's judgment?" } ], "differs": [], "exceptions": [] }, { "uid": "uk-fps:txn.standing-order-payment", "id": "txn.standing-order-payment", "slug": "standing-order-payment", "rail": "uk-fps", "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "page": "uk-fps/standing-order-payment.html", "file": "data/products/uk-fps/standing-order-payment.json", "name": "Standing Order Payment (SOP)", "anchor": "an authorisation of its own", "transaction_type": { "uid": "uk-fps:txn.standing-order-payment", "name": "Standing Order Payment (SOP)", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "effective_since": "Unknown: the public documents read do not date the payment types", "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.", "directions": [ "credit" ], "account_types": [ "any" ], "sources": [ { "uid": "uk-fps:src.payuk-fps-system-principles-v11", "name": "Faster Payments System Principles, FPS information guide, v11", "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", "edition": "v11, 2 January 2026", "section": "section 5.2" }, { "uid": "uk-fps:src.payuk-pfmi-self-assessment-2025", "name": "2025 PFMI self-assessment of Pay.UK", "url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "edition": "position as at end of August 2025, published November 2025", "section": "2.2.2" } ] }, "counts": { "rules": 5, "mandates": 1, "states": 0, "code_sets": 0, "reason_codes": 0, "roles": 3, "members": 7 }, "trust": { "members": 7, "by_status": { "draft": 1, "corroborated": 6, "verified": 0, "superseded": 0 }, "strongest_source_class": "public_primary" }, "roles": [ { "uid": "uk-fps:role.central-infrastructure-provider", "name": "Vocalink, the FPS central infrastructure provider", "kind": "service_provider", "via": [ "binds" ] }, { "uid": "uk-fps:role.consumer", "name": "Consumer (reimbursement rules)", "kind": "party", "via": [ "given_by" ] }, { "uid": "uk-fps:role.sending-fps-institution", "name": "Sending FPS Institution", "kind": "institution", "via": [ "given_to", "binds" ] } ], "mandates": [ { "uid": "uk-fps:mandate.standing-order-instruction", "name": "Standing order instruction", "status": "draft", "stored_status": "draft", "source_class": null, "confidence": "low", "tier": { "k": "draft", "label": "Draft, unchecked", "say": "An agent wrote this from published material and nobody has checked it. Treat it as a lead to confirm, not an answer, before acting on any retry, deadline or rate." }, "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" ], "constraints": null, "governed_by": [], "revoked_via": [], "evidenced_by": [], "disputed_via": [], "given_by": [ { "uid": "uk-fps:role.consumer", "name": "Consumer (reimbursement rules)", "note": null } ], "given_to": [ { "uid": "uk-fps:role.sending-fps-institution", "name": "Sending FPS Institution", "note": null } ], "sources": [] } ], "states": [], "code_sets": [], "reason_codes": [], "rules": [ { "uid": "uk-fps:rule.irrevocable-on-submission-to-ci", "name": "A payment is irrevocable the moment it reaches the central infrastructure", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "finality", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "uk-fps:txn.single-immediate-payment", "name": "Single Immediate Payment (SIP)" }, { "uid": "uk-fps:txn.forward-dated-payment", "name": "Forward Dated Payment (FDP)" }, { "uid": "uk-fps:txn.direct-corporate-access", "name": "Direct Corporate Access (DCA) payment" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "uk-fps:src.payuk-pfmi-self-assessment-2025", "name": "2025 PFMI self-assessment of Pay.UK", "url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "edition": "position as at end of August 2025, published November 2025", "section": "key consideration 8.1" }, { "uid": "uk-fps:src.payuk-fps-system-principles-v11", "name": "Faster Payments System Principles, FPS information guide, v11", "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", "edition": "v11, 2 January 2026", "section": "Required Elements, Revocability" } ] }, { "uid": "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds", "name": "A participant retries a standing order or forward dated payment later the same day", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "guidance", "via": "applies_to", "also_applies_to": [ { "uid": "uk-fps:txn.forward-dated-payment", "name": "Forward Dated Payment (FDP)" } ], "parameters": [], "part_of": [], "sources": [ { "uid": "uk-fps:src.payuk-fps-system-principles-v11", "name": "Faster Payments System Principles, FPS information guide, v11", "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", "edition": "v11, 2 January 2026", "section": "sections 5.1, 5.2 and 5.3; Required Elements, Paying Customer Funds" } ] }, { "uid": "uk-fps:rule.standing-orders-90-percent-before-06-00", "name": "At least nine in ten standing orders go out between midnight and 06:00", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [ { "kind": "limit", "text": "at least 90 percent submitted between midnight and 06:00" } ], "part_of": [], "sources": [ { "uid": "uk-fps:src.payuk-fps-system-principles-v11", "name": "Faster Payments System Principles, FPS information guide, v11", "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", "edition": "v11, 2 January 2026", "section": "section 5.2" } ] }, { "uid": "uk-fps:rule.standing-orders-weekdays-only", "name": "Standing orders run on weekdays only", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 1 named source, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "hours", "rests_on": "rule", "via": "applies_to", "also_applies_to": [], "parameters": [], "part_of": [], "sources": [ { "uid": "uk-fps:src.payuk-fps-system-principles-v11", "name": "Faster Payments System Principles, FPS information guide, v11", "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", "edition": "v11, 2 January 2026", "section": "section 5.2" } ] }, { "uid": "uk-fps:rule.system-value-ceiling-one-million", "name": "The central infrastructure rejects a payment above GBP 1,000,000", "status": "corroborated", "stored_status": "corroborated", "source_class": "public_primary", "confidence": "medium", "tier": { "k": "cor", "label": "Corroborated (public primary)", "say": "A validator compared this with 2 named sources, the strongest being an operator or regulator publication. It is not verified: no person has checked it against the current rulebook edition." }, "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.", "facet": "limits", "rests_on": "rule", "via": "applies_to", "also_applies_to": [ { "uid": "uk-fps:txn.single-immediate-payment", "name": "Single Immediate Payment (SIP)" }, { "uid": "uk-fps:txn.forward-dated-payment", "name": "Forward Dated Payment (FDP)" }, { "uid": "uk-fps:txn.direct-corporate-access", "name": "Direct Corporate Access (DCA) payment" } ], "parameters": [ { "kind": "limit", "text": "GBP 1,000,000 for a single payment, enforced by the central infrastructure" } ], "part_of": [ "uk-fps:exc.rejection" ], "sources": [ { "uid": "uk-fps:src.payuk-pfmi-self-assessment-2025", "name": "2025 PFMI self-assessment of Pay.UK", "url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "edition": "position as at end of August 2025, published November 2025", "section": "2.2.2 and its footnote 7" }, { "uid": "uk-fps:src.payuk-fps-transaction-limits-page", "name": "Pay.UK, Faster Payment System transaction limits", "url": "https://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/transaction-limits/", "source_class": "public_primary", "edition": "live page as read 2026-09-20; the page carries no date", "section": "opening paragraph" }, { "uid": "uk-fps:src.payuk-fps-system-principles-v11", "name": "Faster Payments System Principles, FPS information guide, v11", "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", "edition": "v11, 2 January 2026", "section": "Required Elements, Limits (Individual Payment Amount)" } ] } ], "inherited": [ { "facet": "settlement", "label": "Settlement", "question": "How and when does the money settle between institutions?", "fact_uid": "uk-fps:settlement", "fact_name": "How and when does money actually move between the banks?" }, { "facet": "return", "label": "Return", "question": "How does a payment come back, and on what deadline?", "fact_uid": "uk-fps:return", "fact_name": "How does money come back on this rail?" }, { "facet": "recall", "label": "Recall", "question": "Can the sender ask for a payment back, and who decides?", "fact_uid": "uk-fps:recall", "fact_name": "Can a payer get a Faster Payment recalled?" }, { "facet": "refund", "label": "Refund", "question": "Can the payer get the money back, and on what right?", "fact_uid": "uk-fps:refund", "fact_name": "When does a payer get their money back as of right?" }, { "facet": "liability", "label": "Liability", "question": "Who bears a loss when something goes wrong?", "fact_uid": "uk-fps:liability", "fact_name": "Who bears the loss when a Faster Payment goes wrong?" }, { "facet": "consumer-law", "label": "Consumer law", "question": "What does the law give a consumer here, beyond the rulebook?", "fact_uid": "uk-fps:consumer-law", "fact_name": "What does the law give a consumer that the scheme does not?" }, { "facet": "messages", "label": "Messages", "question": "What messages carry the payment and the answers to it?", "fact_uid": "uk-fps:messages", "fact_name": "What does a Faster Payment look like on the wire, and what codes come back?" }, { "facet": "participants", "label": "Participants", "question": "Who may take part, and in what role?", "fact_uid": "uk-fps:participants", "fact_name": "Who can be on the rail, and on what terms?" }, { "facet": "decision-points", "label": "Human decision points", "question": "Where does a rule leave the decision to a bank or a person?", "fact_uid": "uk-fps:decision-points", "fact_name": "Where does a person or a bank actually decide something?" } ], "differs": [ { "facet": "finality", "label": "Finality", "fact_uid": "uk-fps:finality", "fact_name": "When is a Faster Payment final, and can it be undone?", "rules": [ { "uid": "uk-fps:rule.irrevocable-on-submission-to-ci", "name": "A payment is irrevocable the moment it reaches the central infrastructure" } ] }, { "facet": "hours", "label": "Hours", "fact_uid": "uk-fps:hours", "fact_name": "When does the rail run, and how fast must a bank answer?", "rules": [ { "uid": "uk-fps:rule.standing-orders-weekdays-only", "name": "Standing orders run on weekdays only" }, { "uid": "uk-fps:rule.standing-orders-90-percent-before-06-00", "name": "At least nine in ten standing orders go out between midnight and 06:00" }, { "uid": "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds", "name": "A participant retries a standing order or forward dated payment later the same day" } ] }, { "facet": "limits", "label": "Limits", "fact_uid": "uk-fps:limits", "fact_name": "How much can one Faster Payment carry?", "rules": [ { "uid": "uk-fps:rule.system-value-ceiling-one-million", "name": "The central infrastructure rejects a payment above GBP 1,000,000" } ] } ], "exceptions": [ { "uid": "uk-fps:exc.rejection", "name": "Rejection", "shared": true, "via": [ { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "part_of" } ] } ] } ], "thin": [], "candidates": [ { "uid": "apple-pay:txn.in-app-and-web", "name": "Apple Pay payment in an app or on the web", "rail": "apple-pay", "rules": 9, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "au-npp:txn.bsct", "name": "Basic Single Credit Transfer (BSCT)", "rail": "au-npp", "rules": 8, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "bancontact:txn.card-in-store", "name": "Bancontact card payment at a terminal", "rail": "bancontact", "rules": 7, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "bancontact:txn.card-online", "name": "Bancontact card payment online", "rail": "bancontact", "rules": 7, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "bancontact:txn.mobile-p2m", "name": "Mobile Bancontact Transaction, person to merchant", "rail": "bancontact", "rules": 38, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "bancontact:txn.mobile-p2p", "name": "Mobile Bancontact Transaction, person to person", "rail": "bancontact", "rules": 9, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "bancontact:txn.pro-wero", "name": "Bancontact Pro payment settled by Wero", "rail": "bancontact", "rules": 32, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "blik:txn.blik-c", "name": "Contactless BLIK (BLIK-C)", "rail": "blik", "rules": 29, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "blik:txn.cash", "name": "Cash withdrawal or deposit", "rail": "blik", "rules": 30, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "blik:txn.code-payment", "name": "Code payment to a merchant", "rail": "blik", "rules": 32, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "blik:txn.p2p", "name": "Phone transfer (P2P)", "rail": "blik", "rules": 12, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "blik:txn.p2p-request", "name": "Transfer request (P2P-R)", "rail": "blik", "rules": 12, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "blik:txn.refund-to-user", "name": "Refund to the user", "rail": "blik", "rules": 29, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "boleto:txn.cobranca-comum", "name": "Boleto de cobrança, common (comum)", "rail": "boleto", "rules": 6, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "boleto:txn.deposito-e-aporte", "name": "Boleto de depósito e aporte", "rail": "boleto", "rules": 5, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "boleto:txn.proposta", "name": "Boleto de proposta", "rail": "boleto", "rules": 8, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "eps:txn.eps-payment", "name": "eps payment (eps-Überweisung)", "rail": "eps", "rules": 32, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "eps:txn.eps-refund", "name": "eps refund", "rail": "eps", "rules": 9, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "google-pay:txn.card-on-file-payment", "name": "Google Pay payment with a card on file (PAN_ONLY)", "rail": "google-pay", "rules": 10, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "google-pay:txn.device-token-payment", "name": "Google Pay payment with an Android device token (CRYPTOGRAM_3DS)", "rail": "google-pay", "rules": 11, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "in-upi:txn.merchant-payment", "name": "UPI payment to a merchant", "rail": "in-upi", "rules": 5, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "pix:txn.pix-agendado", "name": "Pix Agendado (scheduled Pix)", "rail": "pix", "rules": 5, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "rtp-reject:txn.credit-transfer", "name": "RTP credit transfer (pacs.008)", "rail": "rtp-reject", "rules": 6, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "us-ach:txn.micro-entry", "name": "Micro-entry (account verification)", "rail": "us-ach", "rules": 6, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" }, { "uid": "us-ach:txn.prenote", "name": "Prenotification (prenote)", "rail": "us-ach", "rules": 5, "why": "no authorisation, lifecycle or code set of its own, so a transaction type and not a product" } ], "entry_classes": [ { "uid": "us-ach:txn.tel", "name": "Telephone-Initiated Entry (TEL)", "rail": "us-ach", "rules": 4, "sec_code": "TEL", "anchor": "an authorisation of its own", "why": "A TransactionType that carries a sec_code is the rail's own entry class, whatever authorisation rules it has, and is never a product." }, { "uid": "us-ach:txn.web", "name": "Internet-Initiated or Mobile Entry (WEB)", "rail": "us-ach", "rules": 13, "sec_code": "WEB", "anchor": "an authorisation of its own", "why": "A TransactionType that carries a sec_code is the rail's own entry class, whatever authorisation rules it has, and is never a product." } ] }