@validatefin/mcp

@validatefin/mcp

MCP server to validate SEPA, UBL/Peppol, XRechnung, KSeF FA(3), camt.052/053/054, ACH/NACHA, CPA-005 (Canada), Belgian CODA and French CFONB 120 e-invoice / payment / bank-statement files, to read and write SEPA (EPC) and Swiss QR codes, and to convert MT940, BAI2, CODA and CFONB to ISO 20022 camt.053 — 100% locally, no data leaves your machine. Powered by ValidateFin.

Tools

25 tools, grouped by what they take as input.

Tool	Input	What it does
validate_sepa	xml	SEPA Credit Transfer (pain.001) & Direct Debit (pain.008)
validate_ubl	xml	UBL / Peppol BIS Billing 3.0 invoice & credit note
validate_xrechnung	xml	German XRechnung (UBL or CII)
validate_camt	xml	ISO 20022 camt.052 / camt.053 / camt.054
validate_ksef	xml	Polish KSeF FA(3) structured invoice
validate_efactura	xml	Romanian RO e-Factura — the official CIUS-RO Schematron of the Ministry of Finance (ro16931-ubl-1.0.9: EN 16931 core + BR-RO-*), the OASIS UBL 2.1 XSD, and the CUI/CNP check ANAF runs outside the Schematron (ERRIdentif) and that Schematron-only validators miss.
validate_verifactu	xml	Spanish Verifactu / SIF billing records (AEAT) — reports whether the AEAT would reject the submission, with its official code. Two layers: the official AEAT XSD (SuministroLR + SuministroInformacion), then the controls published in Validaciones y errores v1.2.2 (1108, 1114/1115, 1130, 1138/1139, 1142 CuotaRepercutida ±10 €, 1152, 1177, 1189/1190, 1195/1196, 1223). It recomputes the huella, the chained SHA-256 fingerprint that makes the invoice chain tamper-evident — reproducing the three official vectors of the AEAT hash spec. A wrong huella is not a rejection but code 2000 (aceptado con errores). Lists what needs the AEAT censo and cannot run offline. Not certified or endorsed by the Agencia Tributaria.
validate_facturae	xml	Spanish Facturae electronic invoice — the official B2G format (invoicing public administrations via FACe, law 25/2013). Two layers: the official XSD of facturae.gob.es (Ministerio de Hacienda) for versions 3.2 / 3.2.1 / 3.2.2, selected from the root namespace; then coherence controls derived from the schema's own formulas (line TotalCost = Quantity × UnitPrice, GrossAmount, InvoiceTotal = before-tax + tax − withheld, per-tax cuota, batch totals), the form of the NIF/CIF/NIE, and whether a XAdES <ds:Signature> is present — all as warnings, since Facturae/FACe publishes no numbered offline rejection list. States what it cannot check offline: the cryptographic validity of the signature, the NIF against the AEAT censo, the DIR3 codes and the FACe status. Not certified or endorsed by the Ministerio de Hacienda.
validate_fatturapa	xml / contentBase64	Italian FatturaPA — official AdE XSD and the SdI rejection controls (00421, 00422, 00427, 00445, 00471…), with the exact code the SdI would return. Signed .p7m (CAdES) envelopes supported.
validate_fedwire	xml	Fedwire Funds Service ISO 20022 message (US) — the official ISO 20022 XSDs (head.001 BAH + pacs.008 / pacs.009 / pacs.004 / pacs.028 / camt.056 / camt.029), plus the hybrid postal address the Federal Reserve requires from 16 Nov 2026 (triggered by the settlement date in the message, never today's), the ABA 3-7-1 check digit, and header/document coherence. The Fedwire Usage Guidelines are on Swift MyStandards behind a login and are not checked — the response says so.
read_mt103	content	SWIFT MT103 credit transfer → structured JSON: the five SWIFT blocks, every field of block 4 with a plain-language label, and the parsed parties. Field specs sourced from the ECB TARGET2 UDFS (public). The SWIFT Network Validated Rules are not checked.
generate_camt_test	xml	camt.053 test statement from a pain.001 / pain.008
validate_ach	content	US ACH / NACHA fixed-width file
validate_cpa005	content	Canadian CPA-005 / AFT payment file
validate_coda	content	Belgian CODA bank statement (Febelfin)
convert_coda	content	CODA → camt.053
validate_cfonb	content	French CFONB 120 / AFB120 bank statement
convert_cfonb	content	CFONB 120 → camt.053
convert_mt940	content	SWIFT MT940 → camt.053
convert_bai2	content	BAI2 (US/Canada) → camt.053
validate_epc_qr	payload	SEPA EPC QR code payload (EPC069-12)
generate_epc_qr	fields	Build a SEPA EPC QR code payload
validate_swiss_qr	payload	Swiss QR-bill payload (SIX guidelines)
validate_iban	iban	IBAN (mod-97)
validate_aba	routingNumber	US ABA routing number (RTN)

E-invoicing & payments

• validate_sepa — SEPA Credit Transfer (pain.001) & Direct Debit (pain.008): validates against the official ISO 20022 XSD schemas and the EPC Rulebook business rules (IBAN mod-97, BIC, SEPA character set, mandates, Creditor Scheme Identifier, control sums).
• validate_ubl — UBL invoice / credit note (EN 16931, Peppol BIS Billing 3.0 syntax): runs the official EN 16931 Schematron — the same rule set used by the official European e-invoicing validators — and returns the failed business rules with their official IDs (BR-, BR-CO-). Accepts both the UBL and CII syntaxes (auto-detected).

  ⚠️ The Peppol-specific rules (PEPPOL-EN16931-*) are not run. OpenPeppol publishes no licence for its validation artefacts, so we do not redistribute them; written permission has been requested. A file that passes is EN 16931-conformant — necessary, but not sufficient, for Peppol BIS conformance.

• validate_xrechnung — German XRechnung (the German CIUS of EN 16931, mandatory for B2G): runs the official EN 16931 core Schematron + the KoSIT XRechnung BR-DE rules — the same rule sets as the official German validator. Accepts UBL and CII. Returns failed rules with their IDs (BR-, BR-DE-).
• validate_ksef — Polish KSeF FA(3) structured invoice (Krajowy System e-Faktur), mandatory since 1 Feb 2026 (sales > PLN 200m) / 1 Apr 2026 (everyone else): validates against the official Ministry of Finance XSD published on crd.gov.pl — structure, data types, cardinalities and closed code lists (RodzajFaktury, VAT rates) — and clearly reports files still using the retired FA(2) schema. Also 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.
• validate_ach — US ACH / NACHA file (fixed-width Nacha format): validates the 94-character record structure (File Header, Batch Header, Entry Detail, Addenda, Batch/File Control), the ABA routing-number check digit (3-7-1), the entry hash, and all batch & file control totals (debits, credits, entry/addenda count, block count). Decodes returns (addenda 99), Notices of Change (addenda 98) and international entries (IAT, addenda 10-18).
• validate_cpa005 — 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.

QR codes

• 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).
• generate_epc_qr — build the payload of an EPC QR code 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).
• validate_swiss_qr — decode and validate the payload of a Swiss QR-bill (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 the guidelines require a decoder to verify: a QR-IBAN (institution ID in positions 5-9 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 (not the IBAN's mod-97) and the mod-97 check digits of an RF creditor reference. Use spec: "2.4" for the rules that take effect on 14 November 2026; version 2.3 stays valid until November 2027.

Bank statements

• validate_camt — ISO 20022 camt cash-management file — camt.053 (bank-to-customer statement), camt.052 (account report / intraday) or camt.054 (debit/credit notification), versions .02/.06/.08/.10/.11: extracts account, balances and entries (camt.053 also validated against the official ISO 20022 XSD schema).
• validate_coda — Belgian CODA bank statement ("Coded statement of account", the Febelfin standard, version 2.8): 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), the 8-character transaction codes, the explicit debit/credit sign (0 = credit, 1 = debit) and 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, types 101/102) and of the ISO 11649 "RF" creditor reference (mod 97-10, type 100). A wrong structured reference is the most common reason a Belgian payment is never matched to its invoice, and no other free CODA validator verifies it.
• convert_coda — convert a CODA statement to an ISO 20022 camt.053.001.02 XML statement (booked movements only — the detail records under a globalisation would double-count).
• validate_cfonb — French CFONB 120 bank statement ("Relevé de compte sur support informatique", also called AFB120): 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 is overpunched on the last character of the amount (COBOL zoned decimal: { and A–I = credit, } and J–R = debit), 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…) and 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).
• convert_cfonb — convert a CFONB 120 statement to an ISO 20022 camt.053.001.02 XML statement.
• validate_fedwire — validate a Fedwire Funds Service ISO 20022 message (the Federal Reserve's USD RTGS, on ISO 20022 since 14 July 2025). Both halves — the head.001 business application header and the pacs/camt document — are checked against their official ISO 20022 XSD. On top: the hybrid postal address required from 16 November 2026 for all parties and agents (town name + country, at most two free-text lines), the ABA 3-7-1 check digit of every USABA routing number, and header/document coherence. It does not tell you whether Fedwire would accept the message: the Usage Guidelines are on Swift MyStandards behind a login, and the response lists what was skipped.
• read_mt103 — decode a SWIFT MT103 into structured JSON: the five blocks, every field of the text block with a plain-language label, and the parties (account and BIC kept apart). Field specifications come from the European Central Bank TARGET2 UDFS — public and free. The SWIFT Network Validated Rules (C1–C18) are in the paid User Handbook and are not verified.
• convert_mt940 — convert a legacy SWIFT MT940 bank statement (Customer Statement Message) to an ISO 20022 camt.053.001.02 XML statement: parses the balances and transactions, checks that opening balance + turnover = closing balance (RC/RD reversals handled), and returns the camt.053 XML.
• convert_bai2 — convert a BAI2 (Bank Administration Institute, version 2) cash-management statement — the dominant US/Canada format — to an ISO 20022 camt.053.001.02 XML statement: parses the 01/02/03/16/88 record hierarchy, infers the direction from the numeric type code (100–399 credit, 400–699 debit), scales the integer minor-unit amounts by the currency, and checks that opening ledger (010) + turnover = closing ledger (015).

Identifiers & test data

• validate_iban — IBAN (mod-97 checksum, country & length).
• validate_aba — US ABA routing number (RTN): 9-digit structure, the 3-7-1 check digit (mod 10) and the Federal Reserve routing symbol / district.
• generate_camt_test — generate a camt.053 test statement from a pain.001 / pain.008 file.

The XML validation tools take the file content as xml (a string) and return the result (valid/invalid, errors, summary) as JSON. The fixed-width / text formats (validate_ach, validate_cpa005, validate_coda, convert_coda, validate_cfonb, convert_cfonb, convert_mt940, convert_bai2) take the raw file as content; validate_epc_qr and validate_swiss_qr take the decoded QR text as payload; validate_iban takes an iban string and validate_aba a routingNumber. The convert_* tools and generate_camt_test return the generated camt.053 XML, and generate_epc_qr returns the payload text to encode into a QR code.

Install

Add this to your MCP client configuration (Claude Desktop, Cursor, etc.):

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

Then ask your assistant to validate a SEPA, UBL/Peppol, camt.052/053/054, ACH/NACHA, CODA or CFONB file — or to convert an MT940, BAI2, CODA or CFONB statement to camt.053.

Privacy

Validation runs entirely on your machine. No file or data is ever uploaded to a server — the same privacy guarantee as the ValidateFin website.

License

The MCP server code is MIT. It bundles third-party components under their own licenses:

• SaxonJS (© Saxonica) — runs the official Schematron; redistributed under the SaxonJS license (free, used unmodified).
• EN 16931 validation rules (© European Union / ConnectingEurope) — EUPL v1.2. Compiled to a Saxon SEF; the rules themselves are unmodified.
• XRechnung validation rules (© KoSIT) — Apache-2.0. Compiled to a Saxon SEF; the rules themselves are unmodified. The KoSIT NOTICE is reproduced in THIRD-PARTY-NOTICES.txt, shipped with this package.
• RO_CIUS validation rules (© Ministerul Finanțelor, Romania) — EUPL v1.2.
• Peppol BIS 3.0 validation rules (© OpenPEPPOL AISBL) — not included. OpenPeppol publishes no licence for these artefacts and states that its BIS "may not be modified, re-distribute, sold or repackaged […] without the prior consent of OpenPEPPOL AISBL". We have asked for that permission; until it is granted, the artefacts are not shipped.
• libxml2 (libxml2-wasm) — MIT.

Full notices, including which artefacts were modified and how: THIRD-PARTY-NOTICES.txt.

ValidateFin is an independent tool and is not certified or endorsed by OpenPEPPOL, the European Commission, or any Peppol Authority. "Official" refers to the rule sets/schemas used, not to any accreditation of this tool.