PDF Bank Statements: How Meelo Automates Extraction With AI

Meelo builds an onboarding platform that verifies a candidate's identity, company and creditworthiness in seconds, for lenders, leasing companies, insurers, energy suppliers and retailers. A meaningful share of those applications cannot go through a bank connection, leaving nothing but PDF bank statements. Since May 2025, Meelo has used Koncile's OCR API to turn those statements into usable data and feed its own consistency checks and scoring.

What I value in Koncile is its ability to extract any piece of information from a document. That flexibility lets us build every consistency check we need, inside a single document, across several documents, or at the level of a whole application file.
^{Benjamin Kasprzak, Chief Operating Officer, Meelo}

Meelo, the platform that secures customer onboarding

Founded in 2017 and based in Marcq-en-Barœul in northern France, Meelo builds a SaaS onboarding platform combining artificial intelligence, open banking and open data. Three blocks structure it: identity verification, company and director verification, and creditworthiness analysis. Its clients are vehicle leasing companies and captive finance arms, banks, insurers, energy suppliers and retailers, all of whom hand it the decision to open a commercial relationship or turn it down.

Meelo's business comes down to answering a simple question in a very short window: is this candidate who they claim to be, and can they pay? The companies it equips measure that answer in seconds, not days. All of the platform's value therefore rests on its ability to gather, verify and cross-check heterogeneous information with no human in the loop.

When the candidate does not connect their accounts, the PDF is what remains

The most direct route to assessing creditworthiness is a PSD2 bank connection: the candidate authorises access to their accounts, transactions come back structured, and the ratios are computed immediately. That route works, but it does not cover everyone. A significant share of candidates decline to connect their accounts, have no compatible online access, or sit in a journey where the connection is not offered at all. Across the journeys observed at Meelo's clients, that is roughly one application in three.

For those files, the supporting document becomes the basis of the decision again. The candidate sends their last three bank statements, twelve to fifteen pages of PDF, and exactly the same material has to come out of them as a bank connection would have returned: the list of accounts, their IBANs, and the transaction detail line by line, with amount and direction.

The process is easy to describe: the customer sends us their last three statements, Koncile extracts them, Meelo analyses them, and we return the financial ratios and the debt-to-income study in one click. The catch is that everything rests on the quality of that first step. One misread transaction and the debt ratio computed downstream is wrong.
^{Benjamin Kasprzak, Chief Operating Officer, Meelo}

What makes a bank statement hard for a machine to read

A bank statement passes for a simple document. It is not, and bank statement extraction concentrates several difficulties that stack up inside a single file.

The first is structure. A statement is almost never single-account. The same document brings together a current account, one or more savings accounts, sometimes a joint account and the detail of a deferred-debit card. Each block has its own IBAN, its own balance and its own sequence of operations. An engine that simply reads the first IBAN it meets attaches every transaction to the wrong account, and the affordability calculation that follows is meaningless.

The second is layout. Transaction tables run across several pages, and the header identifying which account they belong to does not always repeat. When a table continues onto the next page, the link between the lines and the account is lost silently.

The third is the direction of amounts. Depending on the bank, debit and credit are carried by two separate columns, by the sign of the amount, or by position within a table. The label is never reliable: a transfer described as "VIR SEPA SUCCESSION" can be money in or money out, and getting the direction wrong on a single operation can move a balance by thousands of euros. We go through these three pitfalls, and how to work around them, in our guide to extracting data from bank statements with OCR.

On a statement you very often have several accounts, several IBANs, savings accounts, cards. With what we had before, we had to go back over every line because fields were missing. What interested us was getting the list of accounts directly, with the transactions already attached to the right account.
^{Florent Maret, Lead Tech Engineer, Meelo}

An extraction engine that can reach any field

Koncile's answer rests on one principle: the fields to extract are described in plain language by Meelo's own teams, with no development work and no fixed schema. A general field captures a single value such as the list of accounts present in the document or the holder's name. A table field captures a sequence of repeating rows, here the transactions, each with its date, label, gross amount, direction and the account it belongs to.

That flexibility changes the nature of the work. Rather than waiting for a vendor to add a field to a standard model, Meelo's teams write the reading rule themselves, test it on their own documents and correct it the same day. The rule governing the direction of amounts, for instance, was written explicitly by their data engineers: read the column or the sign, never the label, and return the gross amount with a credit or debit indicator that Meelo then applies according to its own internal conventions.

Every extracted value carries a confidence score, which lets Meelo route only the uncertain fields to a check rather than having whole files reread. Duplicate detection, based on the actual content of the file rather than its name, also avoids reprocessing and re-billing a statement already analysed, which matters in a journey where the same document is frequently sent more than once.

Who does what between Koncile and Meelo

Koncile structures the raw data, Meelo builds its own decision rules on top: each one stays on its own ground.

Extraction and document fraud detection in an onboarding file

Forged supporting documents are a daily reality of onboarding journeys. A payslip whose taxable net has been raised, a retouched tax assessment notice, a bank statement with a few operations removed: these documents circulate, and they drive a lending decision. Two readings complement each other in catching them.

The first concerns what the document says. It rests on the extracted fields and confronts them with the rest of the file: a declared income against the salary actually credited on the statement, the address on a payslip against the one on a proof of residence, the IBAN supplied with the application against the one present on the account. That is Meelo's ground, and it is what extraction flexibility makes possible, since a check is only worth something if it can rely on the exact field it needs.

The second concerns what the document is, independently of its content. Koncile ships a document fraud detection module for that, layering three families of analysis. Forensic examination of the file first, comparing the creating software against the last modifying one, the consistency of the dates held inside the PDF, the structure of the cross-reference table and the number of typeface families present on a single page. Visual integrity next, hunting for recomposed areas, broken alignment and local alterations around an amount or a date, and catching the scanned or photographed documents whose metadata has disappeared. Business plausibility last, testing whether a displayed value is possible under the rules of the sector.

A careful forgery is invisible to the eye. Made on a native PDF, in the same typeface and the same layout, it leaves a trace only in the internal structure of the file, in the technical signature of the editing tool and in pixel-level rendering around the altered field. This is why stacking independent signals matters more than any single test: each anomaly feeds a score with its justifications, returned in the same response as the extracted fields. A platform already running its own scoring engine can therefore plug that reading of the file underneath its business rules, with no second integration and no second vendor. Our nine methods to detect a fake bank statement go through those signals one by one.

From a generic model to one calibrated on real statements

Tuning was done on real documents, in short iterations. The first model applied to multi-account statements correctly identified account information in around ten percent of cases. After restructuring the model with Meelo's teams, that rose to nearly eighty percent, then beyond ninety-five percent once the reading instructions were refined and a stronger engine was brought in. On transaction lines, reading the amount and the direction of the operation now exceeds ninety-nine percent.

Three levers produced that result. The first was treating the list of accounts as a general field in its own right, so that transaction attachment relies on a known structure rather than on order of appearance in the file. The second was making the rule for reading the direction of amounts explicit instead of letting the model infer it. The third was giving Meelo's teams access to the raw OCR output of the document, which let them diagnose failure cases themselves and adjust their instructions without waiting on a round trip.

We worked the model statement by statement, starting from the cases that failed. Going from ten to eighty percent correct reading of account information in a handful of iterations, on documents that heterogeneous, showed us the headroom was in the configuration rather than in the technology.
^{Melvin Dufrane, Data Engineer, Meelo}

Keeping the document route as cheap as the banking route

An application analysed through a bank connection costs Meelo around forty cents. For the document route to be a real alternative rather than a more expensive fallback, it had to land in the same order of magnitude, even though one application means twelve to fifteen pages to process against a single call on the open banking side.

Two mechanisms made that possible. The first is Koncile's Lite mode, a cheaper processing profile than Pro, calibrated for documents whose structure is regular enough. On bank statements it halves consumption at equal volume. The second is billing by page actually processed rather than by API call, combined with free reprocessing of a document already seen. An application sent twice through the journey is billed once.

The choice between the two modes is made use case by use case. On a standard bank statement, Lite holds the expected quality. On a dense document, a poor scan or a layout that varies heavily, Pro remains the right call. The setting is per model, so the higher tier is only paid for where it earns its place.

What the application gains in time and reliability

What used to take up to 30 minutes per file now happens in seconds, without any loss of reliability.

The commercial consequence is wider than the productivity gain. By making the document route as usable and almost as cheap as the bank connection, Meelo can serve applications it would otherwise have had to set aside, without degrading the quality of its analysis.

Chaining our two products makes the promise concrete for the client, and very effective compared with how they handle their files today. On the proof of concept we delivered to a subsidiary of a major banking group, that is exactly what made the difference.
^{Benjamin Kasprzak, Chief Operating Officer, Meelo}

A component the end client never sees

Technically, Meelo calls Koncile's OCR API from its own backend and renders the result inside its platform. The end client never logs into Koncile, never sees the interface and has nothing to configure: they send their documents into the Meelo journey and receive a score. The extraction models, written by Meelo's teams, remain their property and benefit nobody else.

The document scope goes well beyond the bank statement. The first models connected covered the company registration extract, the tax assessment notice, the payslip, the social security certificate and the Luxembourg identity certificate. Each new document type is configured without development work, which means opening a new customer journey takes days rather than a product cycle.

Data handling and compliance

A bank statement is highly sensitive personal data, and the subject was framed from the start of the collaboration. Documents sent by Meelo are deleted automatically fifteen days after processing, a setting activated at their request on the day of go-live. Processing runs on infrastructure hosted in the Paris region, with encryption at rest and in transit, and Koncile is SOC 2 Type II certified.

No client data is used to train third-party models. Because the platform is agnostic as to the underlying language model, an account can be restricted to European or self-hosted engines only, which answers the requirements financial institutions' security teams place on generative AI applied to personal data.

What comes next

Two directions extend the arrangement. The first is widening the document scope to the accounting and tax filings behind business applications, starting with statutory financial statements, where the difficulty changes nature: long, highly structured documents whose line items have to be mapped onto a chart of accounts. The second is cross-checking between documents in the same file, as is already done on underwriting files at Toyota Assurances, where the point is to automatically confront what a candidate declares, what their payslip carries and what their bank statement shows.

Frequently asked questions about bank statement extraction