AI for Document Review in Banking: Packs, Citations and the Second Pair of Eyes

Every regulated decision a bank makes is defended with paper. The account opened, the facility drawn, the shipment paid against a credit, the file refreshed: each rests on documents somebody read, compared and signed for. When an examiner returns to that decision years later, they are testing whether the evidence supported it and whether the person who approved it could have seen that evidence at the time.

The reading is the cheap part. The provenance is the expensive part. So the question is not whether a model can read a certificate of incorporation. It is whether the output arrives in a form a checker and an examiner can both stand behind.

The unit of work is the pack, not the document

Bank teams rarely review a single document. They review a pack: forty items for a corporate onboarding, a credit file, a trade finance presentation, a mortgage submission. Each has an owner, a deadline, a completeness standard and a shelf life, because individual items expire at different rates. A per-document extractor therefore produces a pile of fields nobody can act on. What an operations lead can act on is a requirements matrix: which items the policy demands, which are present, which are stale, which contradict another item, which are missing. That matrix is the deliverable, and extraction is only how it gets built.

Corporate onboarding and the CDD pack

Corporate onboarding is where the volume and the frustration live. A pack holds constitutional documents, a registry extract, a board resolution, signatory lists, a structure chart, licences, tax identifiers and a source of funds narrative, arriving from several jurisdictions in several languages, some certified, some scanned at an angle.

An agent identifies each item, extracts the entity attributes, then does the comparison work that consumes analyst hours: does the legal name on the registry extract match the signed application, character for character, including the suffix. Does the registered address agree across documents. Are the directors in the resolution the directors the registry shows. Was certification performed inside your policy window. None of that needs an analyst until a comparison fails, and the pack then arrives with discrepancies isolated and the rest evidenced.

Proof of address and identity documents

Identity items look simple and are not. Passports, identity cards, driving licences, residency permits, utility bills and bank statements arrive as photographs, redacted copies and copies of copies. An agent extracts the identifiers, checks expiry against the date of certification rather than today, checks an address document against your recency rule, and checks that name and address match the application rather than merely resembling it. The important behaviour is refusal: where image quality is too poor to read a digit with confidence, the output is a request for a better copy, not a guess that flows silently into the customer record.

Beneficial ownership evidence

This is the hardest document work in onboarding. Ownership is established by chaining evidence across a registry extract, a register of members, share certificates, shareholder agreements and trust deeds, with interests multiplied up the chain until they cross the threshold in your policy. Build it as a graph rather than a summary. Each edge asserts that one party holds a stated interest in another and carries a citation to the document and page supporting it, so an analyst can check any link in seconds. Where the chain breaks, the agent names the break: an intermediate entity in a jurisdiction with no public registry, voting rights that diverge from economic rights, a nominee holding with no disclosed principal. Whether control exists despite the shareholding is a judgement, and stays with a person.

The periodic refresh backlog

Refresh backlogs are usually described as a capacity problem. Underneath they are a document problem: the pack assembled years ago holds expired items, items collected under a standard that has since moved, and items nobody indexed properly. An agent can work that document layer without touching the risk decision. It reads each existing pack, ages every item against the current standard, and produces a per-file shortfall list. Grouping shortfalls by customer and document type turns thousands of chases into a few batched outreach lists, which is where the cycle time actually goes, and separates files genuinely short of evidence from files that are complete but poorly indexed.

Credit files and covenant extraction

Credit teams assemble files from facility agreements, security documents, guarantees, conditions precedent checklists and approvals, then extract the terms monitored for years: financial covenants and their test dates, information undertakings and their deadlines, negative pledges and change of control provisions.

The trap is defined terms. A financial covenant is defined inside the agreement itself, with its own add-backs and exclusions, and it is not the measure printed in the statutory accounts. An agent applying a generic understanding of a common metric produces a plausible and wrong monitoring schedule. Capture the definition, with a citation, alongside the covenant.

The second trap is the amendment chain. Waivers, side letters and amendment agreements sit in different folders and often override the original term, so track the chain and flag amended covenants rather than presenting the original as current.

Financial statement spreading

Spreading is extraction plus arithmetic, and the arithmetic should not be done by the model. The agent locates figures across the face of the statements and the notes, because the number an analyst needs is often only in the notes, and hands calculation to ordinary code. Give it one hard control: extracted line items must reconcile to the printed subtotals, and where they do not, the spread stops rather than proceeding with a quiet error. Restated comparatives and differing accounting bases across a group are reasons to route the file to an analyst, not to smooth it over.

Trade finance document checking

Checking a presentation against a documentary credit suits machine assistance unusually well, because the standard is literal. Invoices, transport documents, insurance certificates, packing lists and certificates of origin are checked against the wording of the credit: does the goods description correspond, are dates in sequence, was presentation inside the period, is the document signed in the required capacity, are amounts within tolerance.

An agent can produce a candidate discrepancy list with the credit clause and the document line side by side, which is how a checker wants to see it. What it must not do is decide. Calling a discrepancy, refusing a presentation or seeking a waiver belongs to your checkers.

Mortgage and secured lending file completeness

In secured lending the cheapest win is at intake, before underwriting opens the file. An agent checks that the application, income evidence, valuation, title and searches, insurance, deposit source evidence and identity documents are present and current, that property address and applicant names agree across every document, and that the income evidence supports the figure keyed in. Files that fail go back to the broker or branch the same day with a specific list, rather than consuming an underwriter slot and then waiting for a chase. The underwriting judgement is untouched. Only the queue changes.

Four eyes, citations and what the second reviewer sees

In a regulated bank the control that matters is not the model, it is the review. Two rules keep an agent inside it.

First, every extracted value carries a citation: the source file, the page and the quoted text it came from. A value without a citation is not evidence. That single requirement does more for adoption than any accuracy figure, because it lets a sceptical checker verify a field in seconds rather than reopening the document.

Second, the agent is never one of the two pairs of eyes. Its output is an input to the first reviewer, not a substitute for the second. The maker keeps the maker's responsibility, the checker sees both the agent's output and what the maker changed, and sign off is explicit and attributable to a named person. Where the agent writes into a core system it writes pending records only. Log the policy version in force and the system version behind the extraction, because change control will ask.

Evidence packs for audit and examination

The compounding benefit of building this way is reconstruction. Given a customer and a date, you can show what the file contained at that moment, which policy version applied, which documents were relied upon and who approved the outcome. That is a versioning problem more than a storage problem, and has to be designed in at the start. It also makes remediation tractable: when a control gap is found, you sweep a portfolio for one missing piece of evidence rather than reopening every file by hand.

Where AI fails here

Source quality defeats it. Certified copies of copies, stamps printed across text, handwritten annotations and photographs taken at an angle all degrade extraction, and recognition errors propagate silently. Detecting unusable input is a feature, not a shortfall.

Names across scripts remain genuinely hard. Transliteration, ordering conventions and inconsistent legal suffixes produce both false matches and missed matches. Treat name matching as a screening input, never a settled answer.

Authenticity is out of scope. An agent checks whether a document is internally consistent and consistent with the rest of the pack. It does not tell you whether it is genuine. Forgery detection is a separate control.

Judgement stays human. Whether control exists beyond a shareholding, whether a source of wealth narrative is plausible, whether a discrepancy is worth refusing, whether a covenant breach matters given the relationship: none are reading tasks.

Scale magnifies small error rates. A low error rate across a large refresh population is still many wrong files, so quality assurance does not disappear, it refocuses onto the agent's output. Model risk and audit belong in the room from the first week, not after the pilot.

A first deployment that survives change control

Choose one pack type with a written standard, high volume and a human review step you intend to keep. Write the requirements matrix down first, including the checks your senior people perform from memory, because an agent can only apply rules that exist. Run it alongside current work, compare field by field, and set the acceptance bar before you look at the results.

Adopt AI Partners works back office first for this reason. The document layer is where the evidence lives, where the standard is already written, and where a mistake is caught by a checker.

If you have a pack that takes too long to assemble or a refresh backlog that will not clear, describe the process to Adopt AI Partners and we will tell you plainly which parts an agent should touch and which it should not.