From Manual Review to Exception-Based Digital Onboarding

Digital banking platforms expanding across Latin America rarely encounter one standard onboarding document.

A single implementation may need to process national identity cards, passports, tax records, proof-of-address documents, income evidence, account statements and locally required declarations. Some are standardized cards with stable layouts. Others are paper documents, scanned certificates or semi-structured forms that vary by issuer and jurisdiction.

For a digital banking technology vendor, this creates a scaling problem. Every new institution or country can introduce additional document templates, fields, validation rules and exception paths.

This deployment-derived composite case examines how a digital banking vendor and systems integrator could combine its platform with Finlaris document AI, facial verification and duplicate-detection capabilities.

This composite case draws on anonymized technical patterns from Finlaris deployment experience. The partner profile, industry, geography, commercial model, document mix, volumes and project figures have been generalized or altered and do not describe a specific Finlaris partner.

Digital growth increases onboarding complexity

Latin America’s fintech ecosystem expanded from approximately 700 companies in 2017 to more than 3,000 in 2023, according to research from the Inter-American Development Bank and Finnovista reported by Reuters. Around 57% of the region’s fintech companies targeted unbanked or underbanked consumers. Reuters

The World Bank also identifies fast-payment systems as an important driver of more accessible and convenient digital financial services across Latin America and the Caribbean. World Bank

As more financial services become digital and immediate, onboarding infrastructure must support both growth and control. For a platform vendor, that means processing increasingly diverse identity evidence without allowing every new document or market to become a separate manual project.

The partner profile

The partner in this scenario provides digital banking software and systems-integration services to financial institutions across several Latin American markets.

Its platform supports:

Digital account opening
Customer application workflows
Core-banking integration
Payment-service integration
Business-rule configuration
Customer notifications
Case management
Manual-review queues
Operational reporting

Before adding a common identity layer, its customers handled document review differently. Some relied heavily on operations teams. Others integrated separate OCR and biometric services for each project.

The result was a collection of institution-specific solutions that became harder to maintain as the partner expanded.

The operational problem was not just OCR accuracy

Document OCR is often described as a simple conversion from an image into text. In production onboarding, the problem is more complex.

The system must first determine:

What document has been submitted
Whether the image is usable
Which page or side is present
Which fields should exist
Where those fields are located
Whether the extracted values follow the expected format
Whether multiple documents belong to the same applicant
Whether the applicant’s face matches the identity evidence
Whether the same person has registered previously

A correct OCR value can still be operationally useless if it is associated with the wrong field, wrong document type or wrong applicant.

The solution therefore needed to combine document classification, structured extraction, quality control, facial verification and workflow orchestration.

A common framework for mixed document types

The partner and Finlaris structured the proposed identity layer around three broad document groups.

Standard identity documents

These include national identity cards, residence cards, driving licences and passports with relatively stable layouts.

The workflow can apply:

Document classification
Front-and-back association
Field-level OCR
Date and number-format validation
Portrait extraction
Document-quality checks
Selfie-to-document face comparison

Semi-structured financial and supporting documents

These may include tax certificates, account records, payslips, proof-of-address documents and employer-issued evidence.

Layouts can vary between issuers, but the documents usually contain recognizable semantic fields such as:

Applicant or account-holder name
Document or reference number
Issue date
Employer or institution
Address
Income or account information
Stamp or signature region

Extraction must therefore be field-oriented rather than dependent on one fixed pixel position.

Non-standard declarations and certificates

Some onboarding journeys require locally specific letters, declarations or certificates.

These documents may contain:

Free-form titles
Applicant names
Reference numbers
Signatures
Seals or stamps
Dates
Issuing bodies
Variable text blocks

For these materials, a visual document model can identify semantic regions and extract selected fields even when the layout is not completely standardized.

Moving from manual-first to machine-first review

The partner’s earlier process relied on operations staff to inspect most submissions.

That model created several problems:

Review standards varied between analysts.
New document types required additional training.
Peak application periods created backlogs.
Blurred or incomplete images consumed review time.
Duplicate registration checks were difficult to perform consistently.
Expansion into another country increased operational headcount requirements.

The proposed model reversed the workflow:

Machine review first, human exception handling second.

Documents that pass classification, extraction, quality and consistency checks can continue through the configured workflow. Applications with missing fields, low-confidence extraction, poor image quality or conflicting identity signals are routed to manual review.

Human reviewers therefore concentrate on exceptions rather than repeating predictable checks on every application.

The onboarding control stack

Image-quality gateway

Before OCR or comparison, the system evaluates whether the submitted image is suitable for processing.

Controls may include:

Blur
Low resolution
Glare
Overexposure or underexposure
Cropped edges
Obstruction
Screen or paper recapture
Missing document side
Abnormal orientation

A recapture request at this stage is generally more useful than forcing a low-quality image through the entire workflow.

Document classification and extraction

The document is assigned to an expected type and version. Relevant fields are extracted into a structured response.

Field-level confidence scores can be used to determine whether:

The value is accepted automatically
The applicant is asked to recapture
A specific field is sent for review
The entire document requires manual inspection

Cross-document consistency

Where the journey requires multiple documents, the workflow compares common fields such as:

Full name
Date of birth
Identity number
Address
Issue or expiry date

Normalization is important because spacing, name order, abbreviations and diacritics may vary between documents.

Facial verification

The applicant’s live capture is compared against the portrait extracted from the identity document.

Liveness and presentation-attack detection help distinguish a real capture from printed photos, replayed media or manipulated inputs.

Face 1:N duplicate search

The submitted face can also be searched against an existing registration population.

This supports the identification of:

One face associated with multiple identities
Repeated onboarding attempts
Previously rejected applicants
Duplicate customer profiles
Coordinated registration patterns

The 1:N result should be treated as a candidate match requiring configurable thresholds and, where appropriate, human confirmation—not as an unexplained automatic accusation of fraud.

Production characteristics behind the composite case

The anonymized deployment pattern informing this scenario involved:

Multiple countries and continuing document expansion
A mixture of cards, paper documents and semi-structured certificates
Low five-figure daily document-processing volume
Several thousand daily facial comparison and search requests
Repeated field additions and accuracy optimization
Multiple production iterations over the course of the project
Coordination between product, engineering and acceptance teams

The solution was not treated as a one-time OCR integration. Document coverage and extraction requirements continued to evolve after the initial launch.

That continuing iteration is normal in multi-market onboarding. Issuers update templates, customers add fields, image characteristics change and new fraud patterns emerge.

An example digital-bank implementation

Consider a financial institution launching digital accounts in a second Latin American market.

The partner already provides the account-opening workflow and core-banking integration. The new market introduces:

A different national identity document
An additional tax or registration number
Locally formatted proof-of-address documents
Variations in personal-name structure
Different manual-review requirements

The partner configures the new workflow while Finlaris adds or adjusts the necessary document templates and extraction fields.

The resulting process could be:

Identify the submitted document type.
Evaluate image quality.
Extract the required fields.
Normalize names, dates and identifiers.
Compare information across supporting documents.
Match the applicant’s selfie to the document portrait.
perform liveness and presentation-attack checks.
Search for possible duplicate facial registrations.
Return structured results and confidence values.
Route exceptions to the partner’s review queue.

The financial institution retains responsibility for KYC policy, customer acceptance and manual-review decisions.

Evidence of operational value

The main improvement is not a promotional claim that “AI automated everything.”

It is a change in the operating model:

Standard cases can be processed through consistent machine checks.
Review teams focus on low-confidence and conflicting cases.
New document fields can be introduced without redesigning the entire onboarding platform.
Multiple document types can be processed within one framework.
Duplicate and identity-mismatch risks can be checked earlier.
Review decisions receive structured evidence rather than only raw images.
The same integration can support additional institutions and markets.

These outcomes depend on document quality, customer configuration, thresholds and operating procedures. They should be evaluated during testing rather than presented as universal performance guarantees.

How the partnership creates a repeatable product

The digital banking vendor would own:

Customer-facing workflow
Business-rule configuration
Core-banking and payment integrations
Case-management interface
Customer implementation
First-line platform support
Market-specific delivery

Finlaris would support:

Document classification and OCR
Field-level structured extraction
Image-quality detection
Face comparison
Liveness and presentation-attack detection
Face 1:N search
Document-template expansion
Accuracy optimization
API and SDK integration
Product-level troubleshooting

This creates a reusable identity layer that the partner can configure across different banking customers.

Build multi-market onboarding with Finlaris

Finlaris works with digital banking vendors and systems integrators that need to support more documents, more identity checks and more markets without turning every deployment into a separate technology stack.

By combining the partner’s banking workflows and local delivery capabilities with Finlaris document AI and biometric verification, the two sides can build onboarding systems designed for both expansion and operational control.

Discuss how Finlaris could become the identity and document-intelligence layer within your digital banking platform.