{ "corpus": "orca-conflicts", "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." }, "counts": { "logged": 19, "resolved": 16, "unresolved": 2, "superseded": 1, "records_affected": 38 }, "rule_sources": { "au-npp-reject: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" }, "au-npp-reject:src.westpac-bankrec-npp": { "name": "Westpac BankRec, New Payments Platform (NPP)", "url": "https://bankrec.westpac.com.au/docs/npp/", "source_class": "secondary", "edition": "undated live page, read 2026-09-21" }, "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" }, "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" }, "boleto:src.nuclea-pfmi-report-v4": { "name": "Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4", "url": "https://www2.nuclea.com.br/Compliance/Relat%C3%B3rio%20N%C3%BAclea_%20PFMI%20CPSS-IOSCO.pdf", "source_class": "public_primary", "edition": "version 4, 2026 self-assessment, valid to 2028-07-10, marked public; PDF of 38 pages, 1,353,526 bytes, SHA-256 d6cf927576b0dd9d2431f4cf13de67fc79f8106b77606d92a925e6f66d23c0d5" }, "boleto:src.nuclea-siloc": { "name": "Liquidação de Operações de Crédito, SILOC (Núclea product page)", "url": "https://www.nuclea.com.br/liquidacao-de-operacoes-de-credito-siloc/", "source_class": "public_primary", "edition": "Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19" }, "boleto:src.nuclea-siloc-manual-operacoes": { "name": "Manual de Operações do SILOC (MAPX-OP002-2004), Núclea", "url": "https://www2.nuclea.com.br/Compliance/MAPX-OP002-2004%20-%20Manual%20de%20Opera%C3%A7%C3%B5es%20do%20SILOC.pdf", "source_class": "public_primary", "edition": "version 31.0, in force 12/01/2026 to 12/01/2028 by its page header; PDF of 53 pages, 1,550,999 bytes, SHA-256 8f94b5213f6034a5bad4b274a8051612776a76c538fe5ec9e84e845e4ad2f01d" }, "boleto:src.nuclea-siloc-regulamento": { "name": "Regulamento Operacional do SILOC, Núclea", "url": "https://www2.nuclea.com.br/ProdutosIMF/Regulamento%20Operacional%20do%20SILOC.pdf", "source_class": "authoritative_primary", "edition": "version 4.0, dated 02.01.2026 on its cover and signed São Paulo 2026-01-02, listed on Núclea's documents page as dated 2026-03-20; PDF of 22 pages, 433,656 bytes, SHA-256 362cdd1d07e282cab3a7ade65e752d9a5d1400e051fc667e235495352ca556b5" }, "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)" }, "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" }, "rtp-reject:src.iso20022-external-code-sets-2q2026": { "name": "ISO 20022 External Code Sets, 2Q2026 (ExternalStatusReason1Code)", "url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "edition": "2Q2026 release, file 2Q2026_externalcodesets_v3.json" }, "uk-fps:src.psr-sr1-notice-maximum-reimbursement-level-2024-09": { "name": "PSR Specific Requirement 1, notice of maximum reimbursement level value, September 2024", "url": "https://www.psr.org.uk/media/0w1fmnr5/sr1-max-limit-value-supplementary-sept-2024-publication-version.pdf", "source_class": "authoritative_primary", "edition": "made 25 September 2024, in force 7 October 2024" }, "us-ach:src.jefferson-bank-obligations-of-originators-2022-03": { "name": "Jefferson Bank, Obligations of Originators, revised March 2022", "url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "edition": "revised March 2022, per its page footers" }, "us-ach:src.nacha-differentiating-unauthorized-return-reasons": { "name": "Differentiating Unauthorized Return Reasons (Nacha)", "url": "https://www.nacha.org/rules/differentiating-unauthorized-return-reasons", "source_class": "public_primary", "edition": "public rule page describing the change effective 2020-04-01, as read 2026-09-17" }, "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02": { "name": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02", "url": "https://documents.popular.com/pdfs/PCB/ACH_Rules_Awareness_Guide.pdf", "source_class": "secondary", "edition": "revised 2025-04-02" } }, "conflicts": [ { "id": "us-ach-r11-unauthorized-return-rate", "question": "Do R11 returns count toward the Nacha unauthorized entry return rate threshold of 0.5 percent, and from when?", "records": [ "us-ach:R11", "us-ach:rule.unauthorized-return-rate-threshold" ], "sides": [ { "position": "R11 counts toward the unauthorized entry return rate, from the first phase of the 2020 rule change on 2020-04-01.", "sources": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "section": "Technical, Effective Dates: phase 1 of 2020-04-01 brings R11 under the unauthorized return provisions, the unauthorized entry return rate among them", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.nacha.org/system/files/2024-01/Calculate_Unauthorized_Return_Rate.pdf", "title": "How to Calculate Unauthorized Return Rate (Nacha, January 2024)", "class": "public_primary", "section": "footnote to Calculating Unauthorized Return Rate Threshold: the unauthorized codes are R05, R07, R10, R11, R29 and R51", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://ramp.com/blog/ach-return-codes", "title": "ACH Return Codes Explained: R01 to R85 (Ramp, 2026-07-14)", "class": "secondary", "section": "Nacha return rate thresholds and compliance: names R11 among the codes under the 0.5 percent threshold (its list leaves out R51)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] }, { "position": "Only R05, R07, R10, R29 and R51 count toward the 0.5 percent threshold; R11 does not, because the authorization exists and the error is correctable.", "sources": [ { "url": "https://goach.com/blog/ach-return-codes/", "title": "ACH Return Codes: Complete Reference Guide (GoACH, reviewed August 2026)", "class": "secondary", "section": "Unauthorized Returns: lists five codes under the threshold and says R11 is outside it", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://intellipay.com/understanding-ach-return-codes-why-r10-and-r11-matter-for-your-business/", "title": "Understanding ACH Return Codes: Why R10 and R11 Matter for Your Business (IntelliPay, 2025-06-12)", "class": "secondary", "section": "R10 vs R11 Comparison Table: marks only R10 as counting toward the threshold", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.nacha.org/rules/ach-network-risk-and-enforcement-topics", "title": "ACH Network Risk and Enforcement Topics (Nacha, rule effective 2015-09-18)", "class": "public_primary", "section": "Topic 1, Reducing the Unauthorized Return Rate Threshold: lists R05, R07, R10, R29 and R51; the page predates the 2020 repurposing of R11", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] } ], "status": "resolved", "resolution": { "finding": "R11 counts. Nacha's rule page puts R11 under the unauthorized entry return rate in phase 1, effective 2020-04-01; phase 2, effective 2021-04-01, only extended the Unauthorized Entry Fee to R11, which is the likely source of the later date the record's effective_note hedges on [Inference]. Nacha's January 2024 calculation sheet lists R11 among the six unauthorized codes. The guides that exclude R11 follow the 2015 five-code list, which the 2020 rule changed. Nacha's public text is not the Operating Rules themselves; a licensed reading of the current edition's return rate definition would verify it.", "sources": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "section": "Technical, Effective Dates: phase 1 (2020-04-01) and phase 2 (2021-04-01)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.nacha.org/system/files/2024-01/Calculate_Unauthorized_Return_Rate.pdf", "title": "How to Calculate Unauthorized Return Rate (Nacha, January 2024)", "class": "public_primary", "section": "footnote to Calculating Unauthorized Return Rate Threshold", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ], "on": "2026-09-19" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "us-ach:R11", "rail": "us-ach", "rail_name": "US ACH", "kind": "reason-code", "name": "Entry not in accordance with the terms of the authorization", "effective_status": "corroborated" }, { "uid": "us-ach:rule.unauthorized-return-rate-threshold", "rail": "us-ach", "rail_name": "US ACH", "kind": "Rule", "name": "Unauthorized entry return rate threshold: 0.5 percent", "effective_status": "corroborated" } ] }, { "id": "mastercard-appeal-after-ruling", "question": "Can a Mastercard customer appeal Mastercard's ruling on a dispute between customers?", "records": [ "mastercard:finality" ], "sides": [ { "position": "No. Mastercard may choose to resolve a disagreement between customers, and its resolution is final, with no appeal, review or other challenge.", "sources": [ { "url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "title": "Mastercard Rules, 2 June 2026 edition", "class": "authoritative_primary", "section": "rule 2.1, Standards (p. 58)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "title": "Mastercard Rules, 2 June 2026 edition, read again on 2026-09-22 from the copy downloaded on 2026-09-19", "class": "authoritative_primary", "section": "rule 2.1, the sentence reserving the right to resolve a disagreement between customers and closing it to appeal, review or other challenge, read together with rule 2.1.6, which gives a customer a named written route to have an assessment for noncompliance reviewed within 30 days on payment of a fee", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "Yes, in arbitration and compliance cases. The customer held financially responsible by the ruling may ask Mastercard in writing to reconsider it, and Mastercard must receive that request within 45 calendar days of the ruling.", "sources": [ { "url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "title": "Chargebacks Made Simple Guide, July 2025", "class": "public_primary", "section": "sections 5.6 and 6.6, Appeal Process (pp. 11 and 15)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "title": "Chargebacks Made Simple Guide, July 2025, read again on 2026-09-22 from the copy downloaded on 2026-09-19", "class": "public_primary", "section": "the ruling and appeal sections of the arbitration case chapter and of the compliance case chapter, where a dispute resolution team rules and the customer left carrying the money may put a written request to reconsider, with the mechanics left to a chapter of the Chargeback Guide on Mastercard Connect", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] } ], "status": "resolved", "resolution": { "finding": "The two describe different things and both hold. What rule 2.1 shuts is the door out of Mastercard: the Corporation keeps the sole right to interpret and enforce its Standards, may resolve a disagreement between customers without being obliged to, and what it decides that way is not open to appeal, review or other challenge by the customers. What the guide describes is a door back to Mastercard itself: after its dispute resolution team rules on an arbitration or a compliance case, the customer left carrying the money may put a written request to Mastercard to reconsider, which Mastercard must receive within 45 calendar days of the ruling. A request to the decider to think again is not a challenge to the decision in the sense the rule closes off, and the guide claims no right to have the ruling changed [Inference]. Two things read in the rules support that reading rather than a flat contradiction. The rule that fixes finality is the same one that lets the Corporation depart from its own published processes and put an alternative in their place, so a route Mastercard opens for itself sits inside it. And the same rule carries a named internal route of exactly this shape for a different subject, a written request that the Chief Franchise Officer review an assessment for noncompliance, with a 30 day limit and a fee, so the text does not treat every internal reconsideration as an appeal it has forbidden. What no public text settles is whether the reconsideration can reverse the ruling or only revisit it, because the mechanics sit in a chapter of the Chargeback Guide that is on Mastercard Connect for customers.", "sources": [ { "url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "title": "Mastercard Rules, 2 June 2026 edition", "class": "authoritative_primary", "section": "rule 2.1 and its subsections, in particular the finality sentence, the paragraph allowing an alternative process, and rule 2.1.6 with rule 2.1.7 on reviewing a noncompliance assessment", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "title": "Chargebacks Made Simple Guide, July 2025", "class": "public_primary", "section": "the ruling sections and the appeal sections of the arbitration case and compliance case chapters", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "mastercard:finality", "rail": "mastercard", "rail_name": "Mastercard", "kind": "rail-fact", "name": "When is a Mastercard card payment final, and what can still undo it?", "effective_status": "corroborated" } ] }, { "id": "ch-sic-retail-receive-deadline", "question": "By when must a SIC participant with retail payments in the RTGS service be able to receive instant payments?", "records": [ "ch-sic:participants", "ch-sic-ip:participants", "ch-sic-ip:consumer-law" ], "sides": [ { "position": "No later than November 2026.", "sources": [ { "url": "https://www.snb.ch/dam/jcr:76cdd7c1-828e-47eb-8d5f-d580fdc1881e/sicgiro_access_2023.en.pdf", "title": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025)", "class": "authoritative_primary", "section": "section 2.1, footnote 2 (p. 2)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.snb.ch/dam/jcr:76cdd7c1-828e-47eb-8d5f-d580fdc1881e/sicgiro_access_2023.en.pdf", "title": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), read again on 2026-09-22", "class": "authoritative_primary", "section": "footnote 2 to the admission types, which puts the obligation on every participant with retail payments in the RTGS service by November 2026 at the latest", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "title": "SNB, Report on the SIC System and Disclosure Report 2025", "class": "public_primary", "section": "Report chapter 3, footnote 5 (p. 9)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] }, { "position": "By the end of 2026.", "sources": [ { "url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "title": "SNB, Report on the SIC System and Disclosure Report 2025", "class": "public_primary", "section": "Disclosure Report chapter 1, most important developments in 2025, instant payments (p. 16)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "title": "SNB, Report on the SIC System and Disclosure Report 2025, read again on 2026-09-22", "class": "public_primary", "section": "the developments chapter of the disclosure part, instant payments paragraph (p. 16), where the remaining retail participants are given the end of 2026", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] } ], "status": "resolved", "resolution": { "finding": "November 2026. Both dates are the SNB's own, and the two texts do different jobs. The instruction sheet on admission states what an institution must do to be admitted to the SIC system and to stay in it, and its footnote to the admission types puts the duty to receive instant payments on every participant with retail payments in the RTGS service by November 2026 at the latest. The end of 2026 wording sits in the developments chapter of the disclosure part of the annual report, which recounts what happened during the year just closed and looks ahead in round terms. An admission condition is not moved by a sentence in a narrative chapter, and in effect the two do not contradict each other, because a participant ready in November is also ready by the year end. What the looser date costs a reader is real all the same: planning to the end of 2026 leaves about seven weeks of exposure against the text the SNB admits on. The reading that the annual report rounded the date for a summary paragraph is [Inference]; nothing read says so.", "sources": [ { "url": "https://www.snb.ch/dam/jcr:76cdd7c1-828e-47eb-8d5f-d580fdc1881e/sicgiro_access_2023.en.pdf", "title": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025)", "class": "authoritative_primary", "section": "footnote 2 to the admission types, against section 2.1 which describes the participation the footnote qualifies", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "ch-sic:participants", "rail": "ch-sic", "rail_name": "Swiss Interbank Clearing (SIC)", "kind": "rail-fact", "name": "Who can take part in the SIC RTGS service, and on what terms?", "effective_status": "draft" }, { "uid": "ch-sic-ip:participants", "rail": "ch-sic-ip", "rail_name": "SIC Instant Payments (SIC IP)", "kind": "rail-fact", "name": "Who takes part in the SIC IP service, and who must?", "effective_status": "corroborated" }, { "uid": "ch-sic-ip:consumer-law", "rail": "ch-sic-ip", "rail_name": "SIC Instant Payments (SIC IP)", "kind": "rail-fact", "name": "What consumer protections apply to a SIC instant payment?", "effective_status": "corroborated" } ] }, { "id": "ch-sic-rtgs-weekend-hours", "question": "Is the SIC RTGS service open at weekends?", "records": [ "ch-sic:hours" ], "sides": [ { "position": "No. The RTGS service closes from Saturday 12.00 to Sunday 18.00 as a maintenance window.", "sources": [ { "url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2024/publications0_en/sicsystem_disclosure_2024.en.pdf", "title": "SNB, Report on the SIC System and Disclosure Report 2024 (published September 2025)", "class": "public_primary", "section": "Report chapter 6, operating hours, RTGS service (p. 12)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] }, { "position": "Yes, since April 2025, with the possibility of a closure of a few hours at a weekend after notice.", "sources": [ { "url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "title": "SNB, Report on the SIC System and Disclosure Report 2025", "class": "public_primary", "section": "Report chapter 6, operating hours and clearing day process, RTGS service (p. 12)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] } ], "status": "superseded", "resolution": { "finding": "The 2025 edition of the same SNB report replaces the 2024 edition's description of the weekend closure. The 2024 edition reports on the year 2024, before weekend opening began in April 2025, although it was published in September 2025. The governing operating times are in the SIC Handbook, which is for participants only, so the current practice rests on the SNB's newer report.", "sources": [ { "url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "title": "SNB, Report on the SIC System and Disclosure Report 2025", "class": "public_primary", "section": "Report chapter 6, clearing day process, RTGS service (p. 12)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ], "on": "2026-09-19" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "ch-sic:hours", "rail": "ch-sic", "rail_name": "Swiss Interbank Clearing (SIC)", "kind": "rail-fact", "name": "When is the SIC RTGS service open, and how does its clearing day run?", "effective_status": "corroborated" } ] }, { "id": "ch-sps-rr05-scope", "question": "In the Swiss Payment Standards, does status reason RR05 apply to credit transfers or only to direct debits?", "records": [ "ch-sps-status:RR05" ], "sides": [ { "position": "Direct debits only. The status report guide shades RR05 in the colour it reserves for codes valid only for Swiss direct debits or SEPA Direct Debit.", "sources": [ { "url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "title": "SPS Implementation Guidelines, Status Report (pain.002), version 2.1, 2024-02-20", "class": "authoritative_primary", "section": "section 3.2.4, Table 10 and the shading key above it (pp. 21 and 22, shading read from the rendered page)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps-2026-en.pdf", "title": "SPS Implementation Guidelines, Status Report (pain.002), version 2.2, 2026-02-20, in force from 14 November 2026", "class": "authoritative_primary", "section": "section 3.2.4 and Table 10, with the fill colour of each code cell read out of the page's drawing instructions: the grey of the direct debit marking sits on RR05 as it does on MD01, MD02 and RR12, while AGNT and BE01 carry the separate light blue of the credit transfer marking", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "Credit transfers too. The credit transfer guide names RR05 as the error for a bad regulatory reporting code in a pain.001.", "sources": [ { "url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf", "title": "SPS Implementation Guidelines, Customer Credit Transfer Initiation (pain.001), version 2.2, 2025-02-24", "class": "authoritative_primary", "section": "section 4.3, Regulatory Reporting Details Code, error column (p. 68)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2026-en.pdf", "title": "SPS Implementation Guidelines, Customer Credit Transfer Initiation (pain.001), version 2.3, 2026-02-24, in force from 14 November 2026", "class": "authoritative_primary", "section": "the C level technical specification, the regulatory reporting details code element (p. 71), whose error column still names RR05 beside CH21", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] } ], "status": "unresolved", "resolution": null, "open": "SIX, which publishes both guides, would settle it by aligning the two: taking the direct debit shading off RR05 in Table 10 or naming another error in the credit transfer guide. A bank may answer with any ISO status reason in any case, so a pain.002 carrying RR05 on a credit transfer is possible either way. Three things narrow it. First, the marking is not an artefact of one edition: the SPS 2026 status report guidelines, version 2.2 of 2026-02-20 and in force from 14 November 2026, still put the grey direct debit fill on the RR05 code cell, next to MD01, MD02 and RR12, while AGNT and BE01 carry the light blue credit transfer fill, so the two markings are both live and RR05 has kept the direct debit one. Second, that edition's change history lists only tracker data and the status sequence, so Table 10 was not reopened when the guidelines were renewed. Third, the section the table sits in says that as a rule any value of the ISO external status reason list may be used and that the table lists the values used under the Swiss guidelines, so the shading limits a Swiss usage rather than the ISO value itself. The credit transfer side has since been read in the same edition, and it has not moved either: the SPS 2026 credit transfer guidelines, version 2.3, still name RR05 as an error on the regulatory reporting details code element of a pain.001. So both halves of the disagreement are live in the release that takes effect on 14 November 2026, published on the same day by the same body, and each guide is the more specific text for one half of the question, the credit transfer guide for what a bad regulatory reporting code in a credit transfer earns and the status report guide for what the answering message may carry. Nothing read chooses between them.", "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "ch-sps-status:RR05", "rail": "ch-sps-status", "rail_name": "Swiss Payment Standards Status Report Reasons", "kind": "reason-code", "name": "Regulatory reporting data wrong", "effective_status": "corroborated" } ] }, { "id": "sepa-sdd-ms02-reversal", "question": "Can MS02 be the reason code on a SEPA Direct Debit reversal?", "records": [ "sepa-sdd-core:MS02", "sepa-sdd-b2b:MS02" ], "sides": [ { "position": "Yes. The EPC reason code guidance lists reversal among the R-transactions MS02 is used for, next to reject, return and refusal.", "sources": [ { "url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "title": "EPC173-14 version 8.0, Guidance on reason codes for SDD R-transactions, 28 November 2024", "class": "public_primary", "section": "section 3, reason code table, MS02 row (p. 10)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC114-06%20SDD%20Core%20Inter-PSP%20IG%202025%20V1.0.pdf", "title": "EPC114-06, SDD Core Inter-PSP Implementation Guidelines 2025 version 1.0", "class": "authoritative_primary", "section": "the inter-PSP reversal instruction for a collection, index 2.7 and index 3.27, the code element under the reversal reason, where the usage rule restricts the ISO values", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC301-07%20SDD%20B2B%20Inter-PSP%20IG%202025%20V1.0.pdf", "title": "EPC301-07, SDD B2B Inter-PSP Implementation Guidelines 2025 version 1.0", "class": "authoritative_primary", "section": "the inter-PSP reversal instruction for a collection, index 2.7 and index 3.27, the code element under the reversal reason, carrying the same restriction as the Core guidelines", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "Not as a debtor refusal. In both rulebooks a reversal is started by the creditor or the creditor PSP, and its reason code takes only two values, a duplicate entry or an unspecified reason; neither rulebook ties MS02 to either value.", "sources": [ { "url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "title": "EPC016-06 2025 SDD Core Rulebook version 1.1", "class": "authoritative_primary", "section": "section 4.8.56, AT-R041 (p. 94)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "title": "EPC222-07 2025 SDD B2B Rulebook version 1.1", "class": "authoritative_primary", "section": "section 4.8.53, AT-R041 (p. 88)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] } ], "status": "resolved", "resolution": { "finding": "MS02 does belong on a reversal, and the two texts were answering different questions. The rulebooks describe AT-R041 as an attribute carrying a duplicate entry or an unspecified reason, and they stop there, without naming the ISO codes those values travel as. The EPC's own inter-PSP implementation guidelines for the two schemes do name them, and both restrict the code element under the reversal reason to three values: AM05 for the duplicate, MS02 for a reason the end customer has not specified, and MS03 for a reason the agent has not specified. So the reason code guidance is right to list reversal for MS02, and the rulebooks are right too: the single unspecified reason of the rulebook becomes two ISO codes, chosen by which side left the reason out. What this does change is the meaning of the value on that R-transaction. A reversal is started by the creditor or the creditor PSP, so the end customer whose reason is not specified is the creditor, and MS02 on a reversal is not the debtor refusal the same value carries on a reject or a return. The records for both schemes mark the reversal use as unconfirmed and read MS02 on a reversal through the debtor's refusal.", "sources": [ { "url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC114-06%20SDD%20Core%20Inter-PSP%20IG%202025%20V1.0.pdf", "title": "EPC114-06, SDD Core Inter-PSP Implementation Guidelines 2025 version 1.0", "class": "authoritative_primary", "section": "the inter-PSP reversal instruction for a collection, the code element under the reversal reason at index 2.7 and index 3.27, with its usage rule and the code restrictions listed beneath it", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC301-07%20SDD%20B2B%20Inter-PSP%20IG%202025%20V1.0.pdf", "title": "EPC301-07, SDD B2B Inter-PSP Implementation Guidelines 2025 version 1.0", "class": "authoritative_primary", "section": "the inter-PSP reversal instruction for a collection, the code element under the reversal reason at index 2.7 and index 3.27", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "sepa-sdd-core:MS02", "rail": "sepa-sdd-core", "rail_name": "SEPA Direct Debit Core", "kind": "reason-code", "name": "Refusal by the Debtor", "effective_status": "draft" }, { "uid": "sepa-sdd-b2b:MS02", "rail": "sepa-sdd-b2b", "rail_name": "SEPA Direct Debit B2B", "kind": "reason-code", "name": "Refusal by the Debtor", "effective_status": "corroborated" } ] }, { "id": "ph-instapay-gross-or-net", "question": "Does InstaPay settle in the BSP's RTGS on a gross or a net basis?", "records": [ "ph-instapay:settlement" ], "sides": [ { "position": "Net. The BSP's rules for retail payment settlement speak of each clearing participant's net clearing obligations, settled through a prefunded demand deposit account at the BSP, with a separate account for instant payments.", "sources": [ { "url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "title": "BSP Manual of Regulations for Payment Systems, updated as of December 2025", "class": "authoritative_primary", "section": "section 701.2, items a to c (p. 69)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] }, { "position": "Gross. The BSP's RTGS rulebook example has the InstaPay operator send a batch gross result for settlement, while its PESONet example sends a batch net result.", "sources": [ { "url": "https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf", "title": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022), PhilPaSSplus, version 1.6, 2026-05-29", "class": "authoritative_primary", "section": "business scenario 3 for InstaPay (p. 119) and the PESONet scenario after it (p. 125)", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] } ], "status": "resolved", "resolution": { "finding": "Net. InstaPay settles each participant's net clearing obligation, and it does so in the BSP's real time gross settlement system; the word gross in the question belongs to the venue, not to the method. The BSP's own InstaPay FAQ, published by its payment system oversight department, names InstaPay and says both things in one answer: settlement runs through PhilPaSS, the BSP's RTGS, and what is settled there are net clearing obligations, prefunded in each participant's demand deposit account at the BSP. That is the BSP text naming InstaPay's settlement method that the question waited on, and it agrees with MORPS section 701.2. The rulebook side does not stand against it once read closely: the rulebook's flow for a switch operator's batch (section 4.25) treats a gross and a net batch as the same pacs.009 message and speaks of the bank's gross or net position, and in the InstaPay example every line moves money between one participant and BancNet's own account, a pay-in and pay-out shape, rather than between the two banks of a customer payment. The label batch gross result therefore describes how that sample message is laid out, not the settlement design [Inference]. What stays unpublished is the cycle count, the cut-offs and the thresholds, which sit in PPMI's rules; Circular No. 1196 (2024), read the same day, changes only which BSP accounts may be used and says nothing on gross or net.", "sources": [ { "url": "https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf", "title": "BSP InstaPay FAQ (fact sheet of the Payment System Oversight Department)", "class": "public_primary", "section": "answer on how InstaPay operates (p. 1)", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf", "title": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022), PhilPaSSplus, version 1.6, 2026-05-29, read again", "class": "authoritative_primary", "section": "section 4.25, positive flow of a third-party batch gross or net transfer (p. 63), against business scenario 3, the debtor and creditor of each transaction in the InstaPay example", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "ph-instapay:settlement", "rail": "ph-instapay", "rail_name": "Philippines InstaPay", "kind": "rail-fact", "name": "How and where do InstaPay payments settle between institutions?", "effective_status": "corroborated" } ] }, { "id": "pix-rr04-rejecting-participant", "question": "Which participant rejects a Pix whose payer is under UN Security Council sanctions, with RR04?", "records": [ "pix-reject:RR04" ], "sides": [ { "position": "The payer's participant, the one holding the payer's transactional account.", "sources": [ { "url": "https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Resolu%C3%A7%C3%A3o%20BCB&p2=1", "title": "Regulamento Pix, annexed to Resolucao BCB n. 1/2020, consolidated text", "class": "authoritative_primary", "section": "art. 38, item V, in the wording given by Resolucao BCB n. 402/2024", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] }, { "position": "The receiving user's participant; the payment is not rejected when it is the receiver who is sanctioned.", "sources": [ { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PACS002.xlsx, Tabela de Dominios, RR04 row, comment and raising participant", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PACS002.xlsx, Tabela de Dominios, the raising participant line on every value in the table, counted across the whole sheet: each one names either the SPI or the receiving user's participant, and none names the paying user's participant", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] } ], "status": "resolved", "resolution": { "finding": "The two texts are both the BCB's and they answer different questions. The Regulamento imposes a duty: the participant providing the paying user's transactional account has to refuse a Pix that moves funds coming from a payer under United Nations Security Council sanctions. It names no message and no code. The catalog answers which participant puts the RR04 value into the rejection message that answers an order already sent, and that is the receiving user's participant. Nothing in the catalog's answer could have been the payer's participant, because the payer's participant does not send that message at all: across the whole rejection code table every value names either the settlement system or the receiving user's participant as the one that raises it. The payer's participant discharges the duty earlier, by not putting the order into the system. The two also agree on the trigger, a payer who is sanctioned, and the catalog adds that an order is not to be rejected when the sanctioned party is the receiving user, which sits with the wording of the duty, about funds coming from sanctioned payers. What no text read states is what the receiving participant acts on when it raises the value, since the duty in the Regulamento is addressed to the payer's side [Unverified]. The record pix-reject:RR04 says the texts do not reconcile.", "sources": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "Regulamento Pix, art. 38 caput and item V in the wording given by Resolucao BCB n. 402/2024, read from the consolidated text", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PACS002.xlsx, Tabela de Dominios, the RR04 row and the raising participant line on every other value in the same table", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "pix-reject:RR04", "rail": "pix-reject", "rail_name": "Pix Payment Rejects", "kind": "reason-code", "name": "Regulatory Reason", "effective_status": "corroborated" } ] }, { "id": "sa-sarie-launch-circular-hijri-date", "question": "What is the Hijri date of SAMA circular 42047169, which launched sarie?", "records": [ "sa-sarie:finality", "sa-sarie:hours", "sa-sarie:limits", "sa-sarie:liability", "sa-sarie:messages", "sa-sarie:participants", "sa-sarie:recall", "sa-sarie:refund", "sa-sarie:return", "sa-sarie:settlement" ], "sides": [ { "position": "6 Rajab 1442 H, with the Gregorian date 17 February 2021.", "sources": [ { "url": "https://rulebook.sama.gov.sa/en/instant-payments-launch-sarie", "title": "SAMA Rulebook, Instant Payments Launch (SARIE), circular 42047169, English translation", "class": "public_primary", "section": "document header, Gregorian and Hijri dates", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://rulebook.sama.gov.sa/sites/default/files/en_net_file_store/SAMA_EN_2572_VER1.pdf", "title": "SAMA, scan of the signed original circular 42047169, linked from the rulebook portal as the original PDF", "class": "authoritative_primary", "section": "the registration block at the head of page one, which carries the circular number and the date written as year, month and day in the Hijri calendar, the month being the seventh; the file holds no text layer and was read as an image", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "7 Rajab 1442 H.", "sources": [ { "url": "https://rulebook.sama.gov.sa/ar/entiresection/10681", "title": "SAMA Guide to Financial Institutions Services Fees, circular 472038000 of 2025-12-22 (Arabic original)", "class": "authoritative_primary", "section": "art. 9, footnote 3", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] } ], "status": "resolved", "resolution": { "finding": "6 Rajab 1442 H. The scan of the signed original, which the rulebook portal offers next to its translation, carries a registration block at the head of the first page holding the circular number and, beneath it, the date in the Hijri calendar as year 1442, month 7, day 6. That is the portal header's date, so the portal is faithful to the document it publishes. The later fees guide gives the next day, and nothing read explains where that came from; a footnote citing an older circular is the kind of place a date is copied rather than checked [Inference]. The Gregorian date was never in dispute. The scan holds no text layer and was read as an image, which is why an earlier pass could not settle it. The records that date this circular follow the portal header and agree with the original.", "sources": [ { "url": "https://rulebook.sama.gov.sa/sites/default/files/en_net_file_store/SAMA_EN_2572_VER1.pdf", "title": "SAMA, scan of the signed original circular 42047169", "class": "authoritative_primary", "section": "the registration block at the head of page one, number and Hijri date", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "sa-sarie:finality", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "When does a sarie payment become final, and can it be reversed?", "effective_status": "corroborated" }, { "uid": "sa-sarie:hours", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "When does this rail operate, and when do payments move?", "effective_status": "corroborated" }, { "uid": "sa-sarie:limits", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "How much can move in one payment, and who sets the limit?", "effective_status": "corroborated" }, { "uid": "sa-sarie:liability", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "Who bears the loss when a payment goes wrong?", "effective_status": "draft" }, { "uid": "sa-sarie:messages", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "What messages carry a payment and its exceptions on this rail?", "effective_status": "corroborated" }, { "uid": "sa-sarie:participants", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "Who can be on this rail, in what roles, and who cannot?", "effective_status": "corroborated" }, { "uid": "sa-sarie:recall", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "Can the sender or the sending bank pull a payment back, and how?", "effective_status": "corroborated" }, { "uid": "sa-sarie:refund", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "Does the payer have a right to get money back, and on what terms?", "effective_status": "draft" }, { "uid": "sa-sarie:return", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "Can the receiving side send a payment back, on what grounds, and by when?", "effective_status": "corroborated" }, { "uid": "sa-sarie:settlement", "rail": "sa-sarie", "rail_name": "Saudi Arabia sarie (instant payments)", "kind": "rail-fact", "name": "How and in what money do participants settle with each other?", "effective_status": "draft" } ] }, { "id": "gcc-afaq-launch-date", "question": "When did AFAQ, and its cross-currency service, start?", "records": [ "gcc-afaq:finality" ], "sides": [ { "position": "AFAQ launched on 10 December 2020.", "sources": [ { "url": "https://www.gulf-payments.com/en/our-services/", "title": "Gulf Payments Company, Our Services", "class": "public_primary", "section": "AFAQ description", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] }, { "position": "The cross-currency AFAQ service went live in December 2021.", "sources": [ { "url": "https://www.gulf-payments.com/en/gpc_news/facilitating-cross-border-payments-in-gcc/", "title": "Gulf Payments Company news, Facilitating cross-border payments in GCC (2023-06-19, reprinted interview)", "class": "public_primary", "section": "account of the service's history", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] }, { "position": "Saudi participants ran a pilot phase from 19 April 2021 to the close of business on 17 July 2021.", "sources": [ { "url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "title": "SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 (2021-12-02)", "class": "authoritative_primary", "section": "section 1, definition of the pilot phase", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ] } ], "status": "resolved", "resolution": { "finding": "The dates name three different events and do not contradict one another: the launch of the AFAQ system in December 2020, a pilot for Saudi participants from April to July 2021, and the cross-currency service in production from December 2021. A record that dates AFAQ names the event it means. The GPC interview is the only public text dating the cross-currency go-live, and it is a reprinted interview [Unverified against a GPC or SAMA notice].", "sources": [ { "url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "title": "SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 (2021-12-02)", "class": "authoritative_primary", "section": "section 1, definition of the pilot phase; sections 3.2 and 3.4, the six months after the pilot", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" }, { "url": "https://www.gulf-payments.com/en/our-services/", "title": "Gulf Payments Company, Our Services", "class": "public_primary", "section": "AFAQ description", "read_on": "2026-09-19", "read_by": "oc6-worker-2026-09-19" } ], "on": "2026-09-19" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-worker-2026-09-19", "affects": [ { "uid": "gcc-afaq:finality", "rail": "gcc-afaq", "rail_name": "GCC AFAQ (cross-currency payments)", "kind": "rail-fact", "name": "When does an AFAQ payment become final, and can it be reversed?", "effective_status": "corroborated" } ] }, { "id": "boleto-siloc-settlement-day", "question": "When SILOC nets a boleto paid below the VR-Boleto, does interbank settlement happen on the day the payer pays or on the following day?", "records": [ "boleto:rule.siloc-settlement-timing", "boleto:settlement", "boleto:hours" ], "sides": [ { "position": "The same day: Núclea's SILOC page lists boletos among its settlement models as settled on the payment day. Read literally the SILOC operating rulebook agrees, because it ties the two boleto cycles to the boletos of a given business day and then puts every moment of those cycles, up to the transfer of the net credits at 08:20 and 16:10, on that same business day.", "sources": [ { "source": "boleto:src.nuclea-siloc", "section": "Formas de Liquidação: the boleto line of the settlement models", "read_on": "2026-09-19", "read_by": "boleto-worker-2026-09-19" }, { "source": "boleto:src.nuclea-siloc-regulamento", "section": "art. 14, the opening sentence and the funds transfer table for boleto cycles", "read_on": "2026-09-20", "read_by": "boleto-siloc-worker-2026-09-20" } ] }, { "position": "The next day: Núclea's 2026 PFMI disclosure says SILOC runs two settlement cycles, both on the day after the items are processed and cleared, the second one regularising inconsistencies. The rulebook fits this too, because the times it fixes cover only the funds transfer stage, and a first cycle whose money moves at 08:20 cannot carry payments made through the business day it settles on; on that reading the business day the rulebook names is the day the money moves, and the processing and clearing of those payments fell on the business day before.", "sources": [ { "source": "boleto:src.nuclea-pfmi-report-v4", "section": "principle 8, KC 2 (p. 17)", "read_on": "2026-09-19", "read_by": "boleto-worker-2026-09-19" }, { "source": "boleto:src.nuclea-siloc-regulamento", "section": "art. 9, the stages of the boleto cycle, against art. 14, which times only the funds transfer stage; arts. 8, 13 and 38, which leave each stage's routines and deadlines to the SILOC manual of operations", "read_on": "2026-09-20", "read_by": "boleto-siloc-worker-2026-09-20" } ] } ], "status": "resolved", "resolution": { "finding": "Both, one per cycle, and neither Núclea page is right on its own. Núclea's SILOC manual of operations, which the rulebook names as the home of each stage's deadlines and which Núclea now publishes, splits the boleto timetable into two blocks. The afternoon cycle runs entirely on the date its payments were processed: the last partial clearing result at 15:00, the final one by 15:05, deposits from 15:20 to 15:50 and the transfer of net credits at 16:10. The morning cycle's settlement falls on the business day after processing: a partial clearing result by 01:00 (02:00 after a national holiday), the final one by 05:10, deposits from 07:00 to 08:00 and the transfer at 08:20. A boleto on the netting route therefore settles the day the payment is processed when it makes the afternoon cycle, and the next business day morning when it does not. The SILOC page's same day reading holds for the afternoon cycle and the PFMI disclosure's next day reading holds for the morning cycle; the disclosure's statement that both cycles fall on the day after is contradicted by the manual for the second. Two things stay open without reopening the question: the exact clock time at which a payment misses the afternoon cycle, which the manual leaves to a separate SILOC processing manual, and whether processing follows the payer's payment on the same day, which depends on when the receiving institution reports it to the central platform; that the afternoon partials close near 15:00 is [Inference] from the timetable.", "sources": [ { "source": "boleto:src.nuclea-siloc-manual-operacoes", "section": "section 11.1, the boleto (Cobrança) cycle, its processing, clearing and funds transfer stages and the partial and final clearing result times (pp. 20 to 23), and 11.1.1, the timetable, whose first block is headed as settlement stages on the next business day and whose second as settlement stages on the date of processing (pp. 24 and 25)", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-19", "logged_by": "boleto-worker-2026-09-19", "affects": [ { "uid": "boleto:rule.siloc-settlement-timing", "rail": "boleto", "rail_name": "Boleto (Brazil payment slip arrangement)", "kind": "Rule", "name": "SILOC settles boletos in two cycles: 16:10 the same business day, 08:20 the next", "effective_status": "corroborated" }, { "uid": "boleto:settlement", "rail": "boleto", "rail_name": "Boleto (Brazil payment slip arrangement)", "kind": "rail-fact", "name": "How and when does a boleto settle between institutions?", "effective_status": "corroborated" }, { "uid": "boleto:hours", "rail": "boleto", "rail_name": "Boleto (Brazil payment slip arrangement)", "kind": "rail-fact", "name": "What times and deadlines govern boleto payments?", "effective_status": "corroborated" } ] }, { "id": "us-ach-reinitiation-count-after-funds-return", "question": "How many times may an Originator reinitiate a debit entry that was returned for insufficient or uncollected funds?", "records": [ "us-ach:rule.reinitiation-after-funds-return", "us-ach:rule.return-re-presenting-a-failed-debit" ], "sides": [ { "position": "Only one reinitiation is allowed: a debit returned for insufficient or uncollected funds may be sent again a single time, within 180 days of the original entry's settlement date.", "sources": [ { "source": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "page 11, Returns: returned entries may be reinitiated if returned for insufficient or uncollected funds and can only be reinitiated one time within 180 days of the original entry", "read_on": "2026-09-19", "read_by": "oc6-conflicts-worker-2026-09-19" } ] }, { "position": "Up to two further reinitiations are allowed, three attempts at the debit in all, each within 180 days of the original entry's settlement date.", "sources": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "page 3, re-initiation paragraph, and the R01 and R09 rows of the Return Reason Codes Table on pages 7 and 8", "read_on": "2026-09-19", "read_by": "oc6-conflicts-worker-2026-09-19" }, { "source": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "page 6, Reinitiation of ACH Entries: the entry may be reinitiated up to two times within 180 days of the settlement date, contradicting page 11 of the same guide", "read_on": "2026-09-19", "read_by": "oc6-conflicts-worker-2026-09-19" } ] } ], "status": "resolved", "resolution": { "finding": "Nacha's own public text supports the two-reinitiation reading, three attempts in all. Nacha's Minor Rules Topics page, for the rule set effective 2019-01-01, states plainly that an editorial change to Article Two, Subsection 2.12.4.1 clarifies the existing intent that reinitiation is limited to two times, with no change of intent. Nacha's ACH Network Risk and Enforcement Topics page, for the rule set effective 2015-09-18, describes the same Reinitiation Rule being formalized into the express limited circumstances of Subsection 2.12.4, referencing ACH Operations Bulletin number 3-2013, a participant-only document not read here. Jefferson Bank's own guide states the two-reinitiation figure on page 6 and the one-reinitiation figure on page 11, an internal inconsistency; its page 6 figure agrees with Popular Bank and with Nacha's public text, so the page 11 figure is the error.", "sources": [ { "url": "https://www.nacha.org/rules/minor-rules-topics-1", "title": "Minor Rules Topics (Nacha)", "class": "public_primary", "section": "Reinitiation: an editorial change clarifying that reinitiation is limited to two times, no change to intent, Article Two Subsection 2.12.4.1, effective 2019-01-01", "read_on": "2026-09-19", "read_by": "oc6-conflicts-worker-2026-09-19" }, { "url": "https://www.nacha.org/rules/ach-network-risk-and-enforcement-topics", "title": "ACH Network Risk and Enforcement Topics (Nacha, rule effective 2015-09-18)", "class": "public_primary", "section": "Topic 3, Reinitiation of Entries: formalizes the express limited circumstances for reinitiation into Subsection 2.12.4 and requires RETRY PYMT in the Company Entry Description", "read_on": "2026-09-19", "read_by": "oc6-conflicts-worker-2026-09-19" } ], "on": "2026-09-19" }, "open": null, "logged_on": "2026-09-19", "logged_by": "oc6-conflicts-worker-2026-09-19", "affects": [ { "uid": "us-ach:rule.reinitiation-after-funds-return", "rail": "us-ach", "rail_name": "US ACH", "kind": "Rule", "name": "Reinitiation after an insufficient or uncollected funds return", "effective_status": "draft" }, { "uid": "us-ach:rule.return-re-presenting-a-failed-debit", "rail": "us-ach", "rail_name": "US ACH", "kind": "Rule", "name": "Re-presenting a failed debit", "effective_status": "draft" } ] }, { "id": "blik-user-approval-window", "question": "How long does a user have to approve a BLIK code payment in the banking app before it times out?", "records": [ "blik:rule.user-approval-window" ], "sides": [ { "position": "60 seconds from the start of the payment, after which the customer must request a new BLIK code.", "sources": [ { "source": "blik:src.stripe-blik", "section": "BLIK payment method overview: customers have 60 seconds to authorize the payment after starting a payment, and it times out after that", "read_on": "2026-09-19", "read_by": "oc6-conflicts-worker-2026-09-19" } ] }, { "position": "45 seconds from the push notification, within which the shopper must authorize the payment. A second processor, on another host, describes the same flow with the same figure and the same starting point.", "sources": [ { "source": "blik:src.adyen-blik", "section": "BLIK payment flow: the shopper must authorize the payment within 45 seconds of the push notification", "read_on": "2026-09-19", "read_by": "oc6-conflicts-worker-2026-09-19" }, { "url": "https://www.docs.pay.sibs.com/payment-methods/blik/", "title": "SIBS Gateway documentation, BLIK", "class": "secondary", "section": "how to use BLIK: the code lives 120 seconds, the push notification follows the shopper choosing to pay, and the confirmation in the banking app has to happen within 45 seconds of it", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] } ], "status": "unresolved", "resolution": null, "open": "PSP's own text would settle this. Neither edition of the BLIK rulebook (both approved 15 April 2026) nor PSP's public FAQ states an approval window in seconds anywhere; both were read in full on 2026-09-19 with no such figure found. The rulebook leaves one-time code handling to the non-public Technical Specification for Participants, Annex 3, cited where the rulebook defines the one-time code and where it addresses rejection of an over-limit transaction. Only a participant reading that Annex, or a PSP statement naming the figure, would show whether either processor's number reflects a scheme rule or its own timeout choice. The gap is narrower than two numbers fifteen seconds apart, because the three processor pages read do not start their clocks at the same moment. Both pages that give 45 seconds start it at the push notification the bank app receives after the shopper presses pay, and one of them sets out the whole sequence in order: code issued, code good for 120 seconds, code entered, pay pressed, push notification, then the 45 seconds. The page that gives 60 seconds starts its clock at the start of the payment, which is the earlier moment, and it gives the code the same two minute life. Read that way the two windows are nested rather than opposed, and the open question is only which of them, if either, is the scheme's own limit rather than a processor's timeout.", "logged_on": "2026-09-19", "logged_by": "oc6-conflicts-worker-2026-09-19", "affects": [ { "uid": "blik:rule.user-approval-window", "rail": "blik", "rail_name": "BLIK", "kind": "Rule", "name": "Time the user has to approve in the app: processors disagree", "effective_status": "corroborated" } ] }, { "id": "au-npp-ac02-meaning", "question": "What does AC02 mean on the NPP: an invalid, missing or unreachable debtor account number, or an account that is closing or closed?", "records": [ "au-npp-reject:AC02", "au-npp:messages" ], "sides": [ { "position": "AC02 is the debtor account number being invalid, missing or not reachable on the platform. The governing authority gives the value the ISO name for an invalid debtor account number and describes the error that way. On this reading a closed account is a different value again, AC05 for the debtor side and AC07 for the creditor side, and the authority's list carries both. The ISO code set the value comes from draws the same line, and a processor's public guide for the same platform follows it.", "sources": [ { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the row for AC02, giving the ISO name and the description of the error", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" }, { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC02 entry read against the AC05 and AC07 entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://gocardless.com/en-au/guides/posts/payto-error-codes-status-codes", "title": "GoCardless, a guide to PayTo error and status codes", "class": "secondary", "section": "the reason code list, the AC02, AC05 and AC07 rows", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "AC02 is an account that is closing or closed. A participant's own published list gives the value that meaning, which on the authority's list would be AC05 or AC07 rather than AC02. The same participant's list carries no AC05 at all.", "sources": [ { "source": "au-npp-reject:src.westpac-bankrec-npp", "section": "the NPP return and reversal codes table, the row for AC02", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" } ] } ], "status": "resolved", "resolution": { "finding": "An invalid, missing or unreachable debtor account number. The value is an ISO 20022 externalised code, and the ISO code set for the current edition gives AC02 the invalid or missing debtor account number and puts a closed debtor account on AC05. Appendix F gives AC02 the same subject and carries AC05 for the closed debtor account, so the authority and the code set agree. The participant's page gives AC02 the closed account meaning the code set keeps for AC05, and that page carries no AC05 at all, which is what a list that has folded the closed account meaning onto AC02 would look like [Inference]. The page names no message, no leg and no code set for its table, so nothing on it supports reading it as a second meaning belonging to the interbank leg; it reads instead as a participant's own list that does not follow the code set. A processor's public guide for the same platform, on a third host, keeps the code set's division. This settles the value for the payment initiation leg the corpus records describe. What a rejected clearing request carries is a separate question and stays outside the corpus, because the NPP Procedures are open to members and direct affiliates only.", "sources": [ { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC02, AC05 and AC07 entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the AC02 row and the AC05 row below it", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-21", "logged_by": "au-npp-drafter-2026-09-21", "affects": [ { "uid": "au-npp-reject:AC02", "rail": "au-npp-reject", "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "kind": "reason-code", "name": "Invalid debtor account number", "effective_status": "corroborated" }, { "uid": "au-npp:messages", "rail": "au-npp", "rail_name": "New Payments Platform (Australia)", "kind": "rail-fact", "name": "What messages does the NPP use, and what codes do they carry?", "effective_status": "corroborated" } ] }, { "id": "au-npp-ac03-meaning", "question": "What does AC03 mean on the NPP: an invalid, missing or unreachable creditor account number, or an account whose status is invalid?", "records": [ "au-npp-reject:AC03", "au-npp:messages" ], "sides": [ { "position": "AC03 is the creditor account number being invalid, missing or not reachable on the platform. The governing authority gives the value the ISO name for an invalid creditor account number and describes the error as a fault in the number.", "sources": [ { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the row for AC03, giving the ISO name and the description of the error", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" }, { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC03 entry read against the AC06 and AC07 entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://gocardless.com/en-au/guides/posts/payto-error-codes-status-codes", "title": "GoCardless, a guide to PayTo error and status codes", "class": "secondary", "section": "the reason code list, the AC03 row", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "AC03 is an account that has an invalid account status. A participant's own published list gives the value that meaning, which is about the state the account is in rather than about the number being wrong.", "sources": [ { "source": "au-npp-reject:src.westpac-bankrec-npp", "section": "the NPP return and reversal codes table, the row for AC03", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" } ] } ], "status": "resolved", "resolution": { "finding": "An invalid, missing or unreachable creditor account number. The value is an ISO 20022 externalised code, and the ISO code set for the current edition gives AC03 a fault in the creditor account number, the mirror of AC02. Appendix F gives it the same subject. The state an account is in, which is what the participant's page attaches to AC03, is carried by other values in the same code set: a blocked account is AC06 and a closed creditor account is AC07, and Appendix F carries both. The participant's page names no message, no leg and no code set for its table, so nothing on it supports a second meaning belonging to the interbank leg. A processor's public guide for the same platform, on a third host, reads AC03 as a fault in the number. This settles the value for the payment initiation leg the corpus records describe; the interbank values stay outside the corpus, because the NPP Procedures are open to members and direct affiliates only.", "sources": [ { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC03, AC06 and AC07 entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the AC03 row and the AC06 and AC07 rows below it", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-21", "logged_by": "au-npp-drafter-2026-09-21", "affects": [ { "uid": "au-npp-reject:AC03", "rail": "au-npp-reject", "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "kind": "reason-code", "name": "Invalid creditor account number", "effective_status": "corroborated" }, { "uid": "au-npp:messages", "rail": "au-npp", "rail_name": "New Payments Platform (Australia)", "kind": "rail-fact", "name": "What messages does the NPP use, and what codes do they carry?", "effective_status": "corroborated" } ] }, { "id": "au-npp-ac06-meaning", "question": "What does AC06 mean on the NPP: a blocked or invalid account on either side, or a branch that cannot be found?", "records": [ "au-npp-reject:AC06", "au-npp:messages" ], "sides": [ { "position": "AC06 is a blocked account. The governing authority gives the value the ISO name for a blocked account and then describes the error as an invalid debtor account or an invalid creditor account, so on its own list the value covers either side. The name and the description do not line up neatly even within that one document.", "sources": [ { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the row for AC06, giving the ISO name and the description of the error", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" }, { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC06 entry read against the AGNT entry", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://gocardless.com/en-au/guides/posts/payto-error-codes-status-codes", "title": "GoCardless, a guide to PayTo error and status codes", "class": "secondary", "section": "the reason code list, the AC06 row, which reads the value as a temporary block on an account the institution can still identify", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "AC06 is a branch that cannot be found. A participant's own published list gives the value that meaning, which is about routing to an institution rather than about the state of an account. On the authority's list a routing failure of that kind would sit closer to AGNT.", "sources": [ { "source": "au-npp-reject:src.westpac-bankrec-npp", "section": "the NPP return and reversal codes table, the row for AC06", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" } ] } ], "status": "resolved", "resolution": { "finding": "An account, not a branch. The value is an ISO 20022 externalised code, and the ISO code set for the current edition gives AC06 an account that is blocked so that nothing may be posted against it. Appendix F prints that same ISO name. A fault in routing to an institution is a different subject in the same code set, carried by AGNT, an agent in the payment workflow that is wrong; Appendix F carries AGNT, and so does the participant's page, with a reference data and agent relationship meaning, so on that page a routing fault sits on two values at once. A processor's public guide for the same platform, on a third host, reads AC06 as a block on an account the institution can still identify. One thing the question asks stays unsettled and is narrower than the disagreement logged here: the authority's own row is uneven, because its description column names an invalid debtor or creditor account rather than a blocked one, so whether an NPP institution sends AC06 for a block or for an account that is invalid on either side is not stated in anything public. The interbank values stay outside the corpus, because the NPP Procedures are open to members and direct affiliates only.", "sources": [ { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC06 and AGNT entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the AC06 row and the AGNT row on the page after it", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-21", "logged_by": "au-npp-drafter-2026-09-21", "affects": [ { "uid": "au-npp-reject:AC06", "rail": "au-npp-reject", "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "kind": "reason-code", "name": "Blocked account", "effective_status": "corroborated" }, { "uid": "au-npp:messages", "rail": "au-npp", "rail_name": "New Payments Platform (Australia)", "kind": "rail-fact", "name": "What messages does the NPP use, and what codes do they carry?", "effective_status": "corroborated" } ] }, { "id": "au-npp-ac07-meaning", "question": "What does AC07 mean on the NPP: a closed creditor account, or an account that cannot be found?", "records": [ "au-npp-reject:AC07", "au-npp:messages" ], "sides": [ { "position": "AC07 is a closed creditor account number. The governing authority gives the value the ISO name for a closed creditor account number and describes the error that way, which makes it the creditor side pair of AC05.", "sources": [ { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the row for AC07, giving the ISO name and the description of the error", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" }, { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC07 entry read against the AC05 and BE06 entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://gocardless.com/en-au/guides/posts/payto-error-codes-status-codes", "title": "GoCardless, a guide to PayTo error and status codes", "class": "secondary", "section": "the reason code list, the AC07 row, which separates an account that once existed and is now permanently closed from an account that does not exist", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] }, { "position": "AC07 is an account that cannot be found. A participant's own published list gives the value that meaning, and an account that never existed is a different state from an account that existed and was closed. On the authority's list an account that cannot be found sits closer to AC03 or BE06.", "sources": [ { "source": "au-npp-reject:src.westpac-bankrec-npp", "section": "the NPP return and reversal codes table, the row for AC07", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" } ] } ], "status": "resolved", "resolution": { "finding": "A closed creditor account number. The value is an ISO 20022 externalised code, and the ISO code set for the current edition gives AC07 a closed creditor account, the creditor side pair of AC05. Appendix F gives it the same subject. An account that cannot be found is a different subject in the same code set, carried by BE06, an end customer not known at the institution or no longer on its books; Appendix F carries BE06 too, and so does the participant's page, with that meaning, so on that page the account that cannot be found sits on two values at once. The page names no message, no leg and no code set for its table, so nothing on it supports a second meaning belonging to the interbank leg. A processor's public guide for the same platform, on a third host, holds the two subjects apart the way the code set does. This settles the value for the payment initiation leg the corpus records describe; the interbank values stay outside the corpus, because the NPP Procedures are open to members and direct affiliates only.", "sources": [ { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AC07, AC05 and BE06 entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the AC07 row and the BE06 row further down the list", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-21", "logged_by": "au-npp-drafter-2026-09-21", "affects": [ { "uid": "au-npp-reject:AC07", "rail": "au-npp-reject", "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "kind": "reason-code", "name": "Closed creditor account number", "effective_status": "corroborated" }, { "uid": "au-npp:messages", "rail": "au-npp", "rail_name": "New Payments Platform (Australia)", "kind": "rail-fact", "name": "What messages does the NPP use, and what codes do they carry?", "effective_status": "corroborated" } ] }, { "id": "au-npp-am02-meaning", "question": "What does AM02 mean on the NPP: an amount that is not allowed, described by the authority as a zero amount, or an amount above the allowed maximum?", "records": [ "au-npp-reject:AM02", "au-npp:messages" ], "sides": [ { "position": "AM02 is an amount that is not allowed, and the governing authority's own description of the error for the value is that the transaction amount cannot be zero. That is the same description it gives AM01 under a different ISO name, so the authority's list does not distinguish the two.", "sources": [ { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the row for AM02, giving the ISO name and the description of the error", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" } ] }, { "position": "AM02 is a payment amount greater than the allowed maximum. A participant's own published list gives the value that meaning, which is the opposite end of the amount range from the authority's description, and the same list gives AM01 the zero amount meaning on its own. The ISO code set the value is drawn from separates the two amount faults the same way, and a processor's public guide for the same platform reads them the same way.", "sources": [ { "source": "au-npp-reject:src.westpac-bankrec-npp", "section": "the NPP return and reversal codes table, the row for AM02", "read_on": "2026-09-21", "read_by": "au-npp-drafter-2026-09-21" }, { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AM02 entry read against the AM01 entry", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "url": "https://gocardless.com/en-au/guides/posts/payto-error-codes-status-codes", "title": "GoCardless, a guide to PayTo error and status codes", "class": "secondary", "section": "the reason code list, the AM02 row against the AM01 row", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ] } ], "status": "resolved", "resolution": { "finding": "An amount above the allowed maximum. The value is an ISO 20022 externalised code, and the ISO code set for the current edition keeps the two amount faults apart: the AM01 entry is an amount of zero and the AM02 entry is an amount over the maximum allowed. Appendix F prints the ISO name for a not allowed amount in the name column against AM02, so the authority adopts the ISO value, and then prints in its description column the same sentence it gives AM01, so the row disagrees with the name it carries. Two lists on different hosts, a participant's own documentation and a processor's public guide for the same platform, both read AM02 as an amount over the maximum and both leave the zero amount meaning with AM01. The likeliest account is that the AM02 description cell was filled from the AM01 row [Inference]; nothing read says so. What stays open is narrower than the question: the authority's note under the appendix leaves an institution free to offer alternative values, so an individual institution may still use either value for either fault. The record au-npp-reject:AM02 was drafted from the description column, and its summary, triggers and actions state the zero amount reading.", "sources": [ { "source": "rtp-reject:src.iso20022-external-code-sets-2q2026", "section": "ExternalStatusReason1Code, the AM01 and AM02 entries", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" }, { "source": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, the AM02 row read across its name and description columns and against the AM01 row above it", "read_on": "2026-09-22", "read_by": "oc6-conflicts-worker-2026-09-22" } ], "on": "2026-09-22" }, "open": null, "logged_on": "2026-09-21", "logged_by": "au-npp-drafter-2026-09-21", "affects": [ { "uid": "au-npp-reject:AM02", "rail": "au-npp-reject", "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "kind": "reason-code", "name": "Not allowed amount", "effective_status": "corroborated" }, { "uid": "au-npp:messages", "rail": "au-npp", "rail_name": "New Payments Platform (Australia)", "kind": "rail-fact", "name": "What messages does the NPP use, and what codes do they carry?", "effective_status": "corroborated" } ] }, { "id": "uk-fps-maximum-reimbursement-level", "question": "What is the most a sending provider has to reimburse on one Faster Payments scam claim: GBP 85,000 or GBP 120,000?", "records": [ "uk-fps:rule.maximum-level-of-reimbursement", "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "uk-fps:liability" ], "sides": [ { "position": "GBP 85,000 for each claim. The regulator fixes the value by notice under Specific Requirement 1 rather than in the scheme rule, the notice has been in force since 7 October 2024, and it runs until the regulator varies or revokes it. The regulator's own consumer page carries the same figure and says a consumer who lost more may take the rest to the Financial Ombudsman Service.", "sources": [ { "source": "uk-fps:src.psr-sr1-notice-maximum-reimbursement-level-2024-09", "section": "paragraphs 1.1 to 1.3: the value, the date it comes into force, and that it continues until varied or revoked", "read_on": "2026-09-21", "read_by": "oc1-uk-fps-worker-2026-09-21" }, { "url": "https://www.psr.org.uk/information-for-consumers/app-fraud-reimbursement-protections/", "title": "Payment Systems Regulator, APP fraud reimbursement protections", "class": "public_primary", "section": "the paragraph on the optional excess and the maximum a person can claim, and the ombudsman limit that sits above it", "read_on": "2026-09-21", "read_by": "oc1-uk-fps-worker-2026-09-21" } ] }, { "position": "GBP 120,000. One directed provider's public page about the mandatory rules gives that as the most a bank may refund. The rest of the same passage matches the regulator: the 13 month reporting limit, the standard of caution, the civil dispute and unlawful payment exclusions, and payments to an account the consumer controlled.", "sources": [ { "url": "https://www.starlingbank.com/blog/protecting-yourself-from-app-fraud/", "title": "Starling Bank, Protecting yourself from APP fraud", "class": "secondary", "section": "the list of situations the mandatory reimbursement rules do not cover, and the sentence after it giving the maximum a bank may refund", "read_on": "2026-09-21", "read_by": "oc1-uk-fps-worker-2026-09-21" } ] } ], "status": "resolved", "resolution": { "finding": "GBP 85,000. The notice of value is the instrument the reimbursement rules point to for this figure, and it sets GBP 85,000, in force from 7 October 2024 and running until the regulator moves it. Nothing read gives GBP 120,000 or shows that it was ever the value, so the provider's page states a figure the regime has not had rather than one that has since changed [Inference]: no source read explains where it came from. The practical size of the gap is GBP 35,000, which is what a consumer reading that page would expect above what the rules require. Three other providers' public pages read the same day, and the ombudsman's own guidance for firms, all give GBP 85,000.", "sources": [ { "source": "uk-fps:src.psr-sr1-notice-maximum-reimbursement-level-2024-09", "section": "paragraph 1.1, the value set, with 1.2 and 1.3 on when it took effect and how long it lasts", "read_on": "2026-09-21", "read_by": "oc1-uk-fps-worker-2026-09-21" }, { "url": "https://www.financial-ombudsman.org.uk/businesses/resolving-complaint/complaints-deal/fraud-scams/app-fraud-scams-involving-authorised-payments", "title": "Financial Ombudsman Service, APP fraud and scams involving authorised payments, guidance for businesses", "class": "public_primary", "section": "reimbursement and the GBP 100 excess, and the worked example under reimbursement and the limit, where a loss above the limit is reimbursed only to it", "read_on": "2026-09-21", "read_by": "oc1-uk-fps-worker-2026-09-21" } ], "on": "2026-09-21" }, "open": null, "logged_on": "2026-09-21", "logged_by": "oc1-uk-fps-worker-2026-09-21", "affects": [ { "uid": "uk-fps:rule.maximum-level-of-reimbursement", "rail": "uk-fps", "rail_name": "Faster Payments (UK)", "kind": "Rule", "name": "Nothing above GBP 85,000 per claim has to be reimbursed", "effective_status": "corroborated" }, { "uid": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "rail": "uk-fps", "rail_name": "Faster Payments (UK)", "kind": "Rule", "name": "Anything paid outside the rules is voluntary, and the receiving side owes nothing toward it", "effective_status": "corroborated" }, { "uid": "uk-fps:liability", "rail": "uk-fps", "rail_name": "Faster Payments (UK)", "kind": "rail-fact", "name": "Who bears the loss when a Faster Payment goes wrong?", "effective_status": "corroborated" } ] } ] }