# ValidateFin [Health: Active]

**Category:** 💰 Finance & Fintech  
**Repository:** https://github.com/elnicaise/validatefin-mcp  
**GitHub Stars:** 1  
**npm Downloads (last month):** 1014  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/validatefin

## Description
Validate SEPA, UBL/Peppol, XRechnung, camt, ACH & IBAN files locally — no data leaves your machine.

## Tools
Capabilities this server exposes over MCP:

- **validate_sepa** — Validate a SEPA payment file — Credit Transfer (pain.001) or Direct Debit (pain.008) — against the official ISO 20022 XSD schemas and the EPC Rulebook business rules: IBAN, BIC, amounts and control sums, plus, for direct debits, the mandate (MndtId + signature date), Creditor Scheme Identifier (ICS) and sequence type. 100% local.
- **validate_ubl** — Validate a UBL invoice or credit note (EN 16931 / Peppol BIS Billing 3.0 syntax) against the OFFICIAL OASIS UBL 2.1 schema (structure: unknown elements, sequence order, data types) AND the OFFICIAL EN 16931 Schematron — the same rule set used by the official European e-invoicing validators. Returns the failed business rules with their official IDs (BR-*, BR-CO-*), schema errors prefixed [XSD]. Accepts both the UBL and CII syntaxes (CII is checked against the official UN/CEFACT CII D16B schema). 100% local. NOTE: the Peppol-specific rules (PEPPOL-EN16931-*) are NOT run — OpenPeppol publishes no licence for its validation artefacts, so they are not redistributed here; permission has been requested. A file that passes is EN 16931-conformant, which is necessary but not sufficient for Peppol BIS conformance.
- **validate_xrechnung** — Validate a German XRechnung invoice — the German CIUS of EN 16931, mandatory for B2G — against the OFFICIAL schema (OASIS UBL 2.1, or UN/CEFACT CII D16B for the CII syntax) plus the OFFICIAL EN 16931 core Schematron and the KoSIT XRechnung BR-DE rules (the same rule sets used by the official German validator). Returns failed rules with their IDs (BR-*, BR-DE-*), schema errors prefixed [XSD]. 100% local.
- **validate_camt** — Validate an ISO 20022 camt cash-management file and extract account, balances and entries: camt.053 (bank-to-customer statement), camt.052 (account report / intraday) or camt.054 (debit/credit notification). Versions .02, .06, .08, .10 and .11. 100% local.
- **validate_efactura** — Validate a Romanian e-invoice (RO e-Factura / RO_CIUS) and report whether ANAF would REJECT it, with the exact rule it would quote. Three layers, in the order ANAF itself runs them: (1) the OASIS UBL 2.1 XSD — Invoice (FACT1) or CreditNote (FCN); (2) the OFFICIAL CIUS-RO Schematron published by the Romanian Ministry of Finance (ro16931-ubl-1.0.9, in force since 05/06/2024), executed as published — it carries both the EN 16931 core rules (BR-*, BR-CO-*, BR-CL-*) and the Romanian ones (BR-RO-001 CustomizationID must be CIUS-RO:1.0.1, BR-RO-020 invoice type code, BR-RO-100/101/160/202 Bucharest SECTOR1-SECTOR6 spelling, BR-RO-030 RON currency, the BR-RO-L* length limits...), with their verbatim Romanian messages; (3) the fiscal-identity check that is NOT in the Schematron and that Schematron-only validators miss entirely — the CUI check digit and the CNP/NIF, which ANAF rejects under its own code ERRIdentif ("CUI cumparator incorect", "CNP sau NIF vanzator incorect"). The CNP check verifies both the check digit AND that the encoded date of birth exists; the anonymous B2C identifier 0000000000000 is recognised as valid. A clean result means the FILE is clean: the summary also lists what only the SPV can check (the depositor identity, the taxpayer registry, the 5-working-day deadline). CII files are refused rather than simulated: the Ministry publishes no Schematron for that syntax. 100% local.
- **validate_verifactu** — Validate a Spanish Verifactu / SIF billing record submission (RegFactuSistemaFacturacion) and report whether the AEAT would REJECT it, with the exact official code it would return. Two layers: (1) the OFFICIAL AEAT XSD (SuministroLR.xsd + SuministroInformacion.xsd) — structure, closed enumerations (TipoFactura F1/F2/F3/R1-R5, CalificacionOperacion S1/S2/N1/N2, ClaveRegimen, TipoHuella), and the DD-MM-AAAA date format; (2) the controls the AEAT publishes in 'Validaciones y errores' v1.2.2 (08/04/2026), quoted with their verbatim Spanish label and code: 1108 (IDEmisorFactura must equal ObligadoEmision), 1114/1115 (TipoRectificativa), 1116/1117/1118/1119 (rectifying and substituting blocks), 1130 (forbidden characters in NumSerieFactura), 1138/1139 (Macrodato at 100,000,000 EUR), 1142 (CuotaRepercutida vs base x rate, tolerance +/-10 EUR), 1152 (no invoice dated before 28/10/2024), 1177 (IdSistemaInformatico), 1189/1190 (Destinatarios vs invoice type), 1195/1196 (CalificacionOperacion and OperacionExenta are exclusive), 1223 (SistemaInformatico NIF xor IDOtro). THE DIFFERENTIATOR: it RECOMPUTES THE HUELLA — the chained SHA-256 fingerprint that makes the invoice chain tamper-evident, where each record hashes the previous record's fingerprint. The implementation reproduces the three official test vectors of the AEAT hash specification (v0.1.2, 27/08/2024). A wrong huella is NOT a rejection: it is code 2000, series 2xxx = 'Aceptado con errores' — the AEAT records the entry anyway, to be corrected. The tool follows the AEAT's own taxonomy, not intuition. It also states what it CANNOT check offline (notCheckedOffline): the NIF against the AEAT censo (1109), duplicates (3000), submission history, the signing certificate (4112), and the clock tolerance (2004) — whose numeric threshold the AEAT publishes nowhere. Independent tool: not certified, approved or endorsed by the Agencia Tributaria. 100% local.
- **validate_facturae** — Validate a Spanish Facturae electronic invoice — the official B2G format required for invoicing Spanish public administrations via FACe (law 25/2013), and one of the accepted B2B formats. Two layers: (1) the OFFICIAL XSD published by facturae.gob.es (Ministerio de Hacienda / Ministerio de Asuntos Económicos), selected from the root namespace — version 3.2 (2009), 3.2.1 (2014) or 3.2.2 (current) — covering structure, data types, cardinalities and closed code lists; (2) COHERENCE controls derived from the schema's own official formulas, reported as warnings (Facturae/FACe publishes no numbered offline rejection list, unlike Italy's SdI): line TotalCost = Quantity x UnitPriceWithoutTax; GrossAmount = TotalCost - discounts + charges; TotalGrossAmountBeforeTaxes = TotalGrossAmount - TotalGeneralDiscounts + TotalGeneralSurcharges; per-tax TaxAmount = TaxableBase x TaxRate; TotalTaxOutputs = sum of tax amounts; InvoiceTotal = TotalGrossAmountBeforeTaxes + TotalTaxOutputs - TotalTaxesWithheld; batch InvoicesCount and TotalInvoicesAmount. It also checks the FORM of the seller/buyer NIF/CIF/NIE (only to flag an impossible form — never a checksum, which no Spanish authority publishes), and whether a XAdES <ds:Signature> is PRESENT. Honest scope, listed on screen (notCheckedOffline): the cryptographic validity of the XAdES signature (certificate chain to a trusted CA, OCSP/CRL revocation, the Facturae signature policy) is NOT verified; nor is the NIF against the AEAT censo, the DIR3 codes (oficina contable / órgano gestor / unidad tramitadora) or the FACe registration status. Independent tool: not certified, approved or endorsed by the Ministerio de Hacienda or facturae.gob.es. Official XSD schemas retrieved from facturae.gob.es on 13 July 2026. 100% local — validating here does not submit the file to FACe.
- **validate_ksef** — Validate a Polish KSeF FA(3) structured invoice (Krajowy System e-Faktur) against the OFFICIAL Ministry of Finance XSD schema published on crd.gov.pl — mandatory since 1 February 2026 (sales over PLN 200m) and 1 April 2026 (everyone else). Checks document structure, data types, cardinalities and closed code lists (RodzajFaktury, VAT rates), recognises and clearly reports files still using the retired FA(2) schema, and additionally reports — as non-blocking warnings — the NIP mod-11 check digit and the coherence of the VAT totals (P_13_*, P_14_*, P_15) with the invoice lines. 100% local.
- **validate_nav** — Validate a Hungarian NAV Online Szamla 3.0 invoice (InvoiceData) and report whether the Hungarian tax authority (NAV) would REJECT it, with the exact code it would quote. EVERY invoice issued in Hungary is reported through this XML, with no threshold, since 2021 - and when completenessIndicator is true the XML IS the electronic invoice itself in the meaning of the Hungarian VAT act, not a mere data report. Two layers: (1) the OFFICIAL NAV XSD, published by the tax authority on github.com/nav-gov-hu under the MIT licence - structure, data types, cardinalities and closed code lists; (2) the rejection controls the NAV publishes itself, each returned with its official ValidatorFaultType and its verbatim English message: INVOICE_LINE_MISSING, LINE_NUMBER_NOT_SEQUENTIAL, SUPPLIER_CUSTOMER_MATCH_TAXPAYER / _NAME / _BANKACCOUNT, INCORRECT_VAT_CODE_SUPPLIER / _CUSTOMER, INCORRECT_DATE_INVOICE_DELIVERY_TO_FROM, INCORRECT_LINE_DATA_SELF_LINE_NUMBER, and the arithmetic (INCORRECT_LINE_CALCULATION_NET_AMOUNT, INCORRECT_SUMMARY_CALCULATION_INVOICE_NET_AMOUNT / _NET_LINE_AMOUNT / _VAT_AMOUNT_SUMMARY / _GROSS_AMOUNT_SUMMARY). Batch invoices (several <invoice> in one file) and header-only modification documents (which legitimately carry no lines) are both handled. Honest scope, returned in notCheckedOffline: invoice-number uniqueness, the customer tax number against the NAV register, the modification chain and the reporter authorisation all require the NAV database. The adoszam check digit is deliberately NOT implemented: no official source publishes the formula. Independent tool: not certified, approved or endorsed by the NAV. 100% local.
- **validate_jpk** — Validate a Polish JPK_V7M(3) VAT control file against the OFFICIAL Ministry of Finance XSD (crd.gov.pl), variant (3), in force since 1 February 2026. THIS IS NOT AN INVOICE and NOT KSeF: a JPK_V7M is the monthly VAT return (<Deklaracja>, the P_* boxes) PLUS the sales and purchase registers (<Ewidencja>, the K_* columns) - and the link between the two is where the value is. Beyond the schema, it reports - as NON-BLOCKING WARNINGS - whether the registers actually feed the return (the sum of each K_* column against the matching P_* box, for the boxes that are a pure sum), whether the control counters match the number of rows, whether the rows are numbered 1, 2, 3..., and the NIP mod-11 check digit. Why warnings and not errors: the Ministry publishes NO numbered list of rejection codes (unlike Hungary or Italy), so no tool can honestly claim that the gateway would reject the file; and the Ministry's own two sample files are internally inconsistent - they declare zero sales rows while carrying one, and use a placeholder NIP that fails its own check digit. Honest scope (notCheckedOffline): the NIP against the register, acceptance by the e-Deklaracje gateway, the KSeF cross-check, and the accounting truth. 100% local.
- **validate_fatturapa** — Validate an Italian electronic invoice (FatturaPA) and report whether the Sistema di Interscambio (SdI) would REJECT it, with the exact rejection code it would return. ⚠️ SCOPE, READ THIS: SdI control 00200 (conformance to the official Agenzia delle Entrate XSD) DOES NOT RUN. The XSD was removed on 13/07/2026 — fatturapa.gov.it forbids reproducing and distributing its content without written consent from the Sistema di Interscambio, which has been requested. So a STRUCTURALLY INVALID invoice (elements out of sequence, a missing mandatory field) can pass every control below and still be bounced by the SdI. `summary.schemaWithheld` is true whenever this applies, and `summary.schemaChecked` is false: do not report such a result as "the SdI would accept this file" — say the substantive controls passed and the structure was not verified. What DOES run: (2) the SdI's own substantive controls, sourced from the "Elenco dei controlli effettuati sul file fattura del SdI" v2.0 (31/01/2025) and reported with their official code and verbatim Italian label — 00301/00306 (fiscal identifier check digits), 00421 (Imposta, tolerance 1 cent), 00422 (ImponibileImporto, tolerance 1 EURO), 00423 (PrezzoTotale), 00424, 00425, 00427 (CodiceDestinatario length vs FormatoTrasmissione), 00428, 00400/00401/00429/00430 (Natura vs AliquotaIVA), 00445 (generic N2/N3/N6, withdrawn 01/01/2021), 00409 (duplicate within a lotto), 00471-00476 (TipoDocumento constraints), and more. Handles FPR12 (private), FPA12 (public administration), FSM10 (simplified) and invoice batches (lotti). Accepts signed CAdES .p7m envelopes via contentBase64 — the envelope is opened and its XML validated, but the SIGNATURE ITSELF IS NOT VERIFIED (that needs the trusted-CA list and an online revocation check: SdI controls 00100-00107). The summary also lists the SdI controls that cannot run offline because they query a government registry (Anagrafe Tributaria, IndicePA, the SdI's duplicate history), so a clean result is never mistaken for a guaranteed acceptance. 100% local.
- **validate_ach** — Validate a US ACH / NACHA file in the fixed-width Nacha format: 94-character records, the record structure (File Header, Batch Header, Entry Detail, Addenda, Batch Control, File Control), the ABA routing-number check digit (3-7-1), the entry hash, and all batch and file control totals (debits, credits, entry/addenda count, block count). 100% local.
- **validate_iban** — Validate an IBAN: length, country code and mod-97 checksum. 100% local.
- **validate_aba** — Validate a US ABA routing number (routing transit number, RTN): 9-digit structure, the ABA 3-7-1 check digit (mod 10) and the Federal Reserve routing symbol / district. The US counterpart of IBAN validation. 100% local.
- **validate_lei** — Validate a Legal Entity Identifier (LEI, ISO 17442): 20-character structure and the check digits (ISO/IEC 7064 MOD 97-10, the same scheme as the IBAN). Returns the LOU prefix, the entity part and, when the checksum fails, the expected check digits. 100% local — no network call. IMPORTANT: a valid checksum only proves the code has no typo. It does NOT prove the LEI exists, which entity it belongs to, or whether it is still active (a LEI must be renewed yearly and can be LAPSED, RETIRED or ANNULLED). Those require the GLEIF Global LEI Repository, an online lookup.
- **validate_creditor_id** — Validate a SEPA Creditor Identifier (ICS / CI) - the identifier that appears in <CdtrSchmeId> of a pain.008 direct debit and on every mandate. Checks the ISO 7064 MOD 97-10 check digits and returns the country, the Creditor Business Code, the national part and, when the checksum fails, the check digits that were expected. THE SUBTLETY THAT BREAKS NAIVE IMPLEMENTATIONS: the Creditor Business Code (positions 5-7, ZZZ when unused) is EXCLUDED from the check-digit calculation - FR72ZZZ123456 and FR72ABC123456 carry the SAME key. Treating the ICS like an IBAN rejects every creditor that uses a custom business code, i.e. precisely the large issuers. Source: EPC262-08 (Creditor Identifier Overview), cross-checked against the Deutsche Bundesbank. A correct checksum only proves the identifier has no typo - it does not prove it was ever issued. 100% local.
- **validate_portugal_qr** — Decode and validate the QR code carried by every Portuguese invoice issued by certified software, and the ATCUD it contains. Sources: the Autoridade Tributaria technical specification (Codigo QR, v1.1) and Portaria 195/2020. Checks the field structure (A to S, in the prescribed order, with their maximum lengths), the amount format (two decimals, dot separator, euro), the document identifier form, the link between the ATCUD sequence number and the document number, the issuer NIF check digit, and the two arithmetic identities the specification implies: total taxes = VAT of the tax spaces + stamp duty, and document total = taxable bases + non-taxed amounts + taxes. Verified against the seven official examples of the specification. TWO THINGS A NAIVE VALIDATOR GETS WRONG: the buyer tax number is only Portuguese when field C is PT (official example 5 carries a FRENCH number, and the field is 30 characters wide precisely for that); and the ATCUD validation-code character set is reported as a WARNING, never an error, because the tax authority publishes a counter-example in its own FAQ. HONEST SCOPE: the ATCUD has NO check digit at all - the validation code is assigned by the tax authority, so no offline tool can say whether it is genuine; the hash (Q) and the software certificate number (R) cannot be verified offline either. 100% local.
- **validate_pix** — Decode and validate a Brazilian Pix payment QR code (BR Code). Sources: the Banco Central do Brasil manuals (Manual do BR Code, and Manual de Padroes para Iniciacao do Pix). Parses the TLV structure and checks the CRC-16 (CCITT-FALSE, polynomial 0x1021, initial value 0xFFFF) - the only field that proves the payload has not been altered; the implementation reproduces the five CRCs of the five official BCB examples. Also checks the payload format indicator, the initiation method, the currency (986 = BRL), the country, the merchant name and city lengths, the amount format, the transaction identifier, and the Pix template itself (the br.gov.bcb.pix GUI, matched case-insensitively): a QR code is either STATIC (it carries the key) or DYNAMIC (it carries a URL) - the two are exclusive - or RECURRING, in which case the URL lives in template 80 and the Pix template may carry only the GUI. When the key is a CPF or a CNPJ, the mod-11 check digits are verified - INCLUDING the ALPHANUMERIC CNPJ introduced in 2026, whose check digits are computed on ASCII minus 48: a digits-only implementation does not merely miss those numbers, it REJECTS them, although they are lawfully issued. HONEST SCOPE: whether the key is registered in the central bank DICT directory, and the JSON payload of a dynamic QR code, cannot be checked offline - reading the latter would mean calling the URL, so the data would leave the machine. 100% local.
- **generate_camt_test** — Generate a valid camt.053 test bank statement from a SEPA pain.001 (credit transfer) or pain.008 (direct debit) file. Returns the camt.053 XML — ideal test data for reconciliation. 100% local.
- **validate_fedwire** — Validate a Fedwire Funds Service ISO 20022 message (the USD real-time gross settlement system of the Federal Reserve, live on ISO 20022 since 14 July 2025). Accepts a bare <Document> or an envelope carrying <AppHdr> + <Document>, and validates each half against its OFFICIAL ISO 20022 XSD: head.001.001.03 for the business application header, and pacs.008.001.08, pacs.009.001.08, pacs.004.001.10, pacs.028.001.03, camt.056.001.08 or camt.029.001.09 for the payment. On top of the schema it checks the hybrid postal address that the Federal Reserve requires from 16 November 2026 (town name + country, at most two free-text lines, for ALL parties and agents) — triggered by the settlement date carried by the message, never by the current date; the ABA 3-7-1 check digit of every USABA routing number; and that the MsgDefIdr of the header names the message it actually encloses. IMPORTANT: the Fedwire Usage Guidelines (mandatory UETR, LclInstrm codes, settlement method) live on Swift MyStandards behind a login and are NOT checked — the response lists what was skipped under `notCheckedOffline`. This tool cannot tell you whether Fedwire would accept a message; it tells you whether it is schema-valid and passes the checks that can be sourced publicly. 100% local.
- **read_mt103** — Decode a SWIFT MT103 (Single Customer Credit Transfer) and return it as structured JSON: the five SWIFT blocks (basic header, application header, user header with the UETR, text block, trailer), every field of block 4 with a plain-language label, and the parsed parties (ordering customer, ordering institution, account with institution, beneficiary — account and BIC kept apart). Checks the mandatory fields (:20:, :23B:, :32A:, :50a:, :59a:, :71A:), the format of :32A:, the OUR/SHA/BEN closed list of :71A:, the mod-97 check digits of an IBAN beneficiary, the format of option-A BICs, and the version-4 UUID form of the UETR. Field specifications are sourced from the European Central Bank TARGET2 UDFS Book 1 (public, free). IMPORTANT: the SWIFT Network Validated Rules (C1-C18) are in the SWIFT User Handbook, which is not freely available, and are NOT checked; TARGET2-specific restrictions are deliberately NOT applied, because they would reject valid messages sent over other rails. Context: the MT/ISO 20022 coexistence on CBPR+ ended 22 November 2025, so MT103 is retired for cross-border interbank traffic and replaced by pacs.008 — but it remains in wide domestic, bank-to-corporate and host-to-host use. 100% local.
- **convert_mt940** — Convert a legacy SWIFT MT940 bank statement (Customer Statement Message) to an ISO 20022 camt.053.001.02 XML statement. MT940 was retired by SWIFT in November 2025 and is being replaced by camt.053. Parses the balances and transactions, checks that opening balance + turnover = closing balance, and returns the camt.053 XML with the real balances and mixed debit/credit entries (RC/RD reversals handled). If the file contains several statements, only the first is converted. 100% local.
- **convert_bai2** — Convert a BAI2 (Bank Administration Institute, version 2) cash-management bank statement — the dominant US/Canada statement format, the North-American counterpart of SWIFT MT940 — to an ISO 20022 camt.053.001.02 XML statement. Parses the 01/02/03/16/88 record hierarchy, infers debit/credit direction from the numeric type code (100–399 credit, 400–699 debit), scales integer minor-unit amounts by the currency, checks that opening ledger balance (010) + turnover = closing ledger balance (015), and returns the camt.053 XML with the real balances and mixed debit/credit entries. If the file contains several accounts, only the first is converted. 100% local.
- **validate_coda** — Validate and read a Belgian CODA bank statement ("Coded statement of account", the Febelfin standard, version 2.8 — the Belgian counterpart of SWIFT MT940, US BAI2 and ISO 20022 camt.053). Parses the fixed-width 128-character record hierarchy (0 header, 1 old balance, 2.1/2.2/2.3 movements, 3.1/3.2/3.3 information, 8 new balance, 4 free communication, 9 trailer), decodes the 8-character transaction codes and the explicit debit/credit sign, and handles the 3-decimal amounts. Checks the trailer control totals and record count (record 9), the accounting identity (old balance ± booked movements = new balance) and — uniquely — the CHECK DIGITS of the Belgian structured communication (+++123/4567/89012+++, mod 97, communication types 101 and 102) and of the ISO 11649 "RF" structured creditor reference (mod 97-10, type 100): a wrong reference is the single most common reason a Belgian payment is never matched to its invoice, and no other free CODA validator verifies it. Returns the balances, the booked movements, the counterparties and every warning as JSON. 100% local.
- **convert_coda** — Convert a Belgian CODA bank statement (Febelfin "Coded statement of account", version 2.8, fixed-width 128-character records) to an ISO 20022 camt.053.001.02 XML statement. Parses the 0/1/2/3/8/4/9 record hierarchy, reads the explicit debit/credit sign and the 3-decimal amounts, keeps only the booked movements (type 2.1 records with detail number 0000 — summing the detail records would double-count them), reconciles old balance ± movements = new balance, and returns the camt.053 XML with the real balances, the counterparty names/accounts and the remittance information. If the file contains several logical CODA files (one per account), only the first is converted. 100% local.
- **validate_cfonb** — Validate and read a French CFONB 120-character bank statement ("Relevé de compte sur support informatique", also called AFB120 — the French counterpart of Belgian CODA, SWIFT MT940, US BAI2 and ISO 20022 camt.053). Parses the fixed-width 120-character records (01 old balance, 04 movement, 05 supplement, 07 new balance) and correctly decodes the two traps of the format: the sign of the amount is OVERPUNCHED on its last character (COBOL zoned decimal — credit "{" and A-I, debit "}" and J-R), so reading that character as a digit both loses the sign and corrupts the last digit; and the number of decimals is a FIELD OF THE FILE (position 20), not a property of the currency. Decodes the SEPA data carried by the 05 records through their 3-letter qualifiers (LIB, MMO, NPY, IPY, NBE, IBE, LCC, LC2, LCS, RCN, REF, CBE, CPY, RUM…): payer and beneficiary, end-to-end reference, mandate reference (RUM) and sequence type, structured and unstructured remittance information, original amount and exchange rate. Checks the accounting identity the CFONB itself requires (§1 rule 2: the new balance equals the algebraic sum of the old balance and of every movement in the statement) — which is also what catches an amount whose sign was written as a plain digit. Returns the balances, the movements and every warning as JSON. 100% local.
- **convert_cfonb** — Convert a French CFONB 120-character bank statement ("Relevé de compte sur support informatique", also called AFB120) to an ISO 20022 camt.053.001.02 XML statement. Parses the 01/04/05/07 fixed-width records, decodes the overpunched sign carried by the last character of each amount (COBOL zoned decimal: "{" and A-I = credit, "}" and J-R = debit) and the number of decimals declared by the file itself at position 20, lifts the SEPA data of the 05 supplement records (payer, beneficiary, end-to-end reference, mandate reference, remittance information) into the camt.053 entries, and reconciles old balance ± movements = new balance. The account is emitted as a domestic identifier, never as a reconstructed IBAN: the CFONB 120 carries the bank code, the branch code and the account number but NOT the RIB key, so an IBAN could only be guessed. If the file contains several statements, only the first is converted. 100% local.
- **validate_cpa005** — Validate a Canadian CPA Standard 005 AFT payment file (also called EFT 1464) — the format Canadian banks use for direct deposits and pre-authorised debits. Records are 1464 characters: a 24-character prefix plus six 240-character segments, so one record carries up to six transactions. Checks the record types (A header, C credit, D debit, E/F error corrections, I/J returns, Z trailer), the logical record count, the origination control data repeated on every record, the FOUR separate pairs of control totals in the Z trailer (error corrections are never folded into the debit/credit totals), the 0YYDDD Julian dates, and the transaction and 900-series return reason codes of CPA Standard 007. Also reads Notice of Change files (U/S/V records). Note: a Canadian routing number has NO check digit — unlike the US ABA number — so only its shape is validated, never an invented checksum. 100% local.
- **validate_epc_qr** — Decode and validate the payload of an EPC QR code (EPC069-12 v3.1) — the "scan to pay" QR code printed on European invoices for a SEPA credit transfer. Checks the twelve-line structure, the BIC (mandatory in version 001, conditional in 002), the beneficiary IBAN (mod-97), the euro amount bounds, the ISO 11649 creditor reference check digits, the mutual exclusivity of the structured reference and the unstructured message, and the 331-BYTE payload cap (bytes of the declared character set, not characters). 100% local.
- **generate_epc_qr** — Build the payload of an EPC QR code (EPC069-12 v3.1) for a SEPA credit transfer, and validate it on the way. Returns the payload text to encode into a QR code (error correction level M). Use version 002 to omit the BIC; version 001 requires it. The amount is written as EUR followed by the value (e.g. EUR12.30), between 0.01 and 999999999.99. A structured creditor reference and an unstructured message are mutually exclusive. 100% local.
- **validate_swiss_qr** — Decode and validate the payload of a Swiss QR-bill (Swiss QR Code, SIX Implementation Guidelines). Checks the 31-to-34-line structure, the fixed values (SPC / 0200 / 1 / EPD trailer), the CH or LI IBAN, the currency (CHF or EUR only), and above all the ACCOUNT/REFERENCE PAIRING that the guidelines require a decoder to verify: a QR-IBAN (an IBAN whose institution ID, positions 5-9, falls between 30000 and 31999) REQUIRES a QRR reference, while a standard IBAN forbids one and takes SCOR (ISO 11649) or NON. Verifies the recursive modulo-10 check digit of the QR reference and the mod-97 check digits of an RF creditor reference. Knows that a bill of exactly 0.00 carrying a "do not use for payment" message is a legitimate notification, not an error. Use spec 2.4 for the rules that take effect on 14 November 2026 (QR-IBAN and QR reference become CHF-only); version 2.3 stays valid until November 2027. 100% local.
- **convert_camt_to_mt940** — Convert an ISO 20022 camt.053 bank statement to SWIFT MT940 text — the reverse of the usual direction, for ERP and accounting systems that cannot read camt XML. Emits :20:/:25:/:28C:/:60F:/:61:/:86:/:62F: (and :64: when the statement carries a closing available balance), one block per statement in the file. Preserves opening and closing balances with their sign, value and booking dates, the customer reference (from EndToEndId) and bank reference (from AcctSvcrRef), and marks reversals with the MT940 RC/RD marks. IMPORTANT LIMITS, which are reported as warnings rather than hidden: only BOOKed entries are emitted (MT940 has no way to express a pending entry, so including one would claim money moved); text is folded into the SWIFT character set, so accents are stripped ("Société Générale" becomes "Societe Generale") and the camt.053 keeps the originals; references are cut to the MT940 limit of 16 characters where camt.053 allows 35. Only camt.053 converts — camt.052 (intraday report) and camt.054 (notification) carry no opening/closing balance pair and are refused rather than given invented balances. 100% local.
- **convert_camt_to_csv** — Flatten an ISO 20022 camt.052, camt.053 or camt.054 into CSV — one row per entry, for Excel, an import mapping or a reconciliation script. Columns: statement, account, booking date, value date, direction, amount, currency, counterparty, counterparty IBAN, end-to-end ID, bank reference, status, reversal, bank transaction code, description. Every statement in a multi-statement file is included. Amounts follow the currency's own minor unit (JPY has no decimals, KWD has three) rather than a hardcoded two. Unlike the MT940 conversion this keeps pending (PDNG) entries, because CSV has a status column and can say so. Cells are guarded against spreadsheet formula injection. 100% local.
- **sepa_dates** — Work out what actually happens to a SEPA payment, and when, from the EPC scheme rulebooks in force and the ECB TARGET calendar. For a direct debit due date, returns the settlement date (a due date on a closed day is NOT an error: the rulebook says settlement moves to the next Inter-PSP Business Day), the latest presentation deadline (D-1 — which applies to EVERY sequence type; the old D-5 for FRST / D-2 for RCUR split was retired in November 2016 and survives only in stale guides), the earliest presentation and latest pre-notification (both 14 CALENDAR days before the due date), the latest return settlement (5 Inter-PSP Business Days for CORE, 3 for B2B), and for CORE the refund window (8 weeks no-questions-asked, 13 months for an unauthorised transaction — B2B has no refund right for an authorised collection at all). Also reports whether TARGET is open on a date and lists a year's six closing days. Sources: ECB long-term TARGET calendar (14/12/2000) and EPC016-06 SDD Core Rulebook 2025 v1.1 / EPC222-07 SDD B2B 2025 v1.0 / EPC125-05 SCT 2025 v1.1. IMPORTANT: this does NOT give a credit transfer settlement date — the SCT rulebook counts in Banking Business Days (days a PSP in the relevant jurisdiction is open for customers), not on the TARGET calendar, and national bank holidays are not knowable from any free source. Bank cut-off times are likewise never asserted. 100% local.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "validatefin": {
    "command": "npx",
    "args": ["-y","@validatefin/mcp"]
  }
}
```

## Documentation

## What ValidateFin MCP server does

ValidateFin MCP server brings local validation of financial file formats into an MCP-compatible workflow. It covers SEPA Credit Transfer and Direct Debit messages, UBL and Peppol BIS Billing 3.0 invoices, German XRechnung invoices, ISO 20022 camt files, US ACH/NACHA files and IBAN values. It also converts legacy SWIFT MT940 statements into camt.053.001.02 XML and can create a camt.053 test statement from a pain.001 or pain.008 document.

The tools apply format checks and, where specified, business-rule validation. SEPA checks use ISO 20022 schemas and EPC rules. UBL and XRechnung validation uses the stated EN 16931, Peppol and KoSIT rule sets, returning failed rules with their identifiers. ACH checks cover fixed-width structure, routing numbers, hashes and control totals.

## How it works

The server runs as a local MCP process. A client sends XML text to the XML validation tools through an `xml` argument. `validate_ach` and `convert_mt940` receive raw file data through `content`, while `validate_iban` accepts an `iban` string. Validation responses are JSON containing the result, errors and a summary. Conversion and test-generation tools return camt.053 XML.

The camt validator accepts camt.052, camt.053 and camt.054 messages in the documented .02, .06, .08, .10 and .11 versions. For camt.053, it extracts account, balance and entry information and also performs the stated ISO 20022 XSD validation. MT940 conversion checks whether the opening balance, turnover and closing balance reconcile, including RC and RD reversals.

## Tools and capabilities

The ValidateFin MCP server exposes these capabilities:

- Validate pain.001 and pain.008 messages against ISO 20022 and EPC checks.
- Validate UBL or CII invoices against EN 16931 and Peppol BIS 3.0 rules.
- Validate UBL or CII XRechnung documents against EN 16931 and KoSIT BR-DE rules.
- Inspect camt.052, camt.053 and camt.054 files, including camt.053 schema validation.
- Check ACH/NACHA record lengths, routing checksums, entry hashes and totals.
- Check IBAN country, length and mod-97 checksum requirements.
- Convert MT940 statements to camt.053.001.02 XML.
- Generate a camt.053 test statement from a SEPA payment or direct-debit file.

## Setup and configuration

Add the server to an MCP client using the `npx -y @validatefin/mcp` command. The documented configuration names the server `validatefin` and uses standard command-and-argument fields, so no service URL or separate account is described. No environment variables are required by the provided setup instructions.

The ValidateFin MCP server performs validation locally. The documentation states that files and other data are not uploaded to a remote server, which makes the local process appropriate for workflows that must keep payment or invoice content on the machine.

## Limitations and notes

The project code is licensed under MIT, while bundled components and rule sets have separate licenses. The documentation specifically lists SaxonJS, EN 16931 rules, Peppol BIS 3.0 rules and libxml2 under their respective licenses.

Using official schemas or rule sets does not mean the tool is certified or endorsed by OpenPEPPOL, the European Commission or a Peppol Authority. That distinction matters when validation results are used in regulated invoicing or payment processes.

_Full upstream README: https://allmcps.com/mcp/validatefin/readme_