RIB and IBAN extraction

A RIB (Relevé d'Identité Bancaire) is the standard French document banks issue to identify an account: it carries the IBAN, BIC, account holder name, and the historic domestic codes (banque, guichet, compte, clé). Finance teams collect them during supplier onboarding, payroll setup, and KYC workflows; treasury and AP teams then keyed them into ERPs and payment platforms by hand for decades. Automated extraction pulls the IBAN, BIC, and holder details straight from the PDF or scan, validates the checksum, and pushes clean data into your payment or onboarding system without a human retyping seventeen characters and hoping they got it right.

Fields to extract

Why this document is hard to process

The RIB looks simple, a single page with a handful of numbers, but it hides several traps. Banks each use their own template: some stack the RIB key and account number in one box, others split them across columns, and legacy scanned formats from older accounts still circulate through fax-quality PDFs. Handwritten annotations (a branch clerk correcting a digit, a customer adding a note) confuse naive OCR. Logos and watermarks vary by bank and sometimes overlap the text region containing the IBAN, causing character-level errors that a plain OCR vs VLM comparison would flag as accuracy loss.

Fraud is the sharper problem. RIBs get intercepted or forged in "change of bank details" scams targeting AP departments; a single wrong digit routes a wire transfer to an attacker's account instead of a supplier's. Because the document carries no signature or seal, verifying authenticity depends entirely on cross-checking the numbers themselves: does the RIB key actually validate against the bank, branch, and account digits? Does the IBAN's checksum pass? Does the account holder name match records on file?

Multi-page bundles compound this: onboarding packets often bundle a RIB with a Kbis extract or an ID card, and extraction has to isolate the right page and the right fields without bleeding data between documents. None of this is exotic, but it demands more than generic text recognition. It demands validation logic built for this specific document.

How Sygnet processes it

Sygnet first classifies the document as a RIB (distinguishing it from a bank statement or invoice attachment), then infers the schema based on the issuing bank's layout rather than forcing every RIB through one rigid template. Each extracted field carries a confidence score and a bounding-box reference back to the source page, so a reviewer can see exactly where the IBAN or account holder name came from, per Sygnet's field-level provenance model.

Validation runs automatically: the IBAN checksum (ISO 7064 MOD 97-10), the French RIB key formula, and BIC-to-bank-code consistency all get checked before the record is marked verified. Cross-document checks compare the account holder name against a Kbis extract or prior KYC record when one is available, catching mismatches that suggest fraud or a simple typo. Records that fail a validation rule, or where OCR confidence on a critical field like the IBAN drops below threshold, get routed to human review; everything else flows straight through as structured output (JSON) into your payment, ERP, or onboarding pipeline via webhook. This keeps review effort concentrated where it actually matters instead of spread evenly across every document, which is the core efficiency argument in our build vs buy IDP comparison.

Validation rules worth applying

• Run the ISO 7064 MOD 97-10 checksum on every IBAN before accepting it.
• Recompute the French RIB key from bank code, branch code, and account number, and reject mismatches.
• Confirm the BIC's bank code segment matches the RIB's bank code.
• Cross-check the account holder name against KYC onboarding or Kbis extract records.
• Flag any RIB where the document date is older than your internal freshness policy.
• Compare against previously stored RIBs for the same supplier; a sudden change in IBAN warrants manual confirmation, especially for AML-sensitive payments.
• Verify the currency field is EUR for domestic French accounts unless the context explicitly expects otherwise.
• Reject documents where the bank name doesn't correspond to a real, registered institution.

FAQ

Can IBAN checksum validation catch every fraudulent RIB?

No. The checksum only confirms the IBAN is mathematically well-formed, not that it belongs to the right person. A fraudster can submit a checksum-valid IBAN tied to their own account. Real protection combines checksum validation with cross-document checks against KYC records and out-of-band confirmation for any change of bank details.

Why does the RIB key formula matter if the IBAN already has a checksum?

The RIB key is a legacy French control digit computed from the bank code, branch code, and account number using a modulo 97 formula, separate from the IBAN's own checksum. Checking both catches errors introduced during a bank's internal formatting or transcription, and it flags inconsistencies between the domestic fields and the IBAN itself.

How does Sygnet handle scanned or faxed RIBs with poor image quality?

Sygnet uses layout analysis and a multimodal approach rather than plain OCR vs VLM text extraction alone, which helps recover structure even when print quality is poor. Fields with low confidence, particularly the IBAN and RIB key, get flagged for human review rather than passed through silently, keeping error rates low on degraded scans.