One application in. Read, scored, written back.
An emailed application and its documents become a scored case in the loan system. A credit officer makes the call.

What goes in, what comes out.
An applicant's email with four documents: the application form, a bank statement, an identity document and a payslip.
A record in the loan system with its status, debt-to-income ratio, rate, notes and checklist, and the credit officer's decision on it.
- 01
Catch the email
Sort it from the rest of the inbox and find the attachments.
- 02
Read every document
Field by field, each value with a confidence score and its place on the page.
- 03
Check them against each other
Income against the payslip, the name against the identity document, the debt-to-income ratio. Then a score and a recommendation.
- 04
Write the record back
Into the loan system, with the verification document uploaded.
- 05
Hand it to a person
The credit officer decides. The report, the audit entry and the disbursement queue follow.
Where a person decides.
The credit officer approves or rejects every case, and can undo a decision. A weak application is escalated, not decided: judgement stays human, the legwork does not. Money never moves on one approval.
- Email inbox
- Loan origination system
- Core banking
- Excel reports
- Audit trail
Mocked in the demonstration. In a delivery, they are yours.
From document to decision, at one of Africa's largest banks.
Previous generation of Roboteur, eight years in production
Before
Before money is paid out on a personal loan, a credit card or an overdraft, the bank checks the signed contract pack against the case, and the applicant's income against statements and payslips. For years teams did this by eye, across five systems, under a service level measured in hours: careful, skilled work that is mostly reading, comparing and re-typing.
- Where
- One of Africa's largest banks
- The work
- Consumer lending, then card disputes, recoveries and deceased estates
- Runs on
- The bank's own servers, on a network with no internet access
- Alongside
- The bank's other automation tools, each where it is strongest
What Roboteur picked up.
Scans, phone photographs, locked PDFs, seven banks' statement layouts and three kinds of signature, read offline, every value kept with its page and position.
Portals behind one-time passcodes, a document viewer and a green-screen mainframe, worked through the interface where there is one and through the screen where there is not.
A review queue where the experts see the proposal, the reason and the evidence on one screen, and decide. People decide; they no longer transcribe.
Rules, flows and dashboards are reviewable text, so a change upstream is a fix in days, not a project.
The experts teach the automation.
Reviewers score every automated report where they read it. Each note is traced to its cause and lands as a rule, a prompt change or a test, and the same cases are re-run so the reviewer sees before and after, side by side, and confirms the fix.
The model elects the salary. The page settles the table. The expert decides the case.

The queue: what came back after each reviewer's notes, ready to confirm. 
The re-run: three dates fixed, a debit removed, a row that was not on the statement dropped.
The bank's real screens, white-labelled, on synthetic cases. Every name and figure in them is invented.
Measured in production.
From the bank's own go-live and monthly reports. Customer, staff and system names are withheld. Every process is different, and yours is measured on its own number.
What it does not do
- It does not decide fraud. A fraud or sanctions hit pauses the case for a named analyst.
- It does not move data off the network. Documents, model calls and decisions stay inside the perimeter.
- It does not replace the bank's systems. It works them.
If your process needs people to run, it's broken.
Pick one process. We design it in a week and prove it in 14 days.