Financial and Document Intelligence

From fragmented financial workflows to intelligent credit operations.

Proposed architectureIllustrative exampleNot published

01 · Business problem

Financing a property involves documents, identity, several banks and follow-up until the keys are delivered. This case shows how Menlo Tech organizes that path into a coordinated flow: it reads and validates documents, measures the confidence of each data point, simulates financial conditions, routes the proposal and tracks every step.

Core principle: Clave validates and coordinates; the financial institution makes the credit decision. Architecture and numbers are phase-one design references, with no measured results.

Someone buying a financed property deals with extensive paperwork and more than one institution. Whoever operates the process must handle many cases in parallel without losing any.

Clave is the layer that organizes that path: it gathers the data, checks what needs checking, sends the proposal to whoever can analyze it and tracks the outcome.

The operational problem

Unstructured documents, in different formats and qualities, with inconsistent data between them.

Identity validation, manual checks, financial calculations outside the flow and several institutions with their own formats and pace.

A complex approval process in which nobody has the full picture of where each proposal stands.

Existing process

  • Documents arrive through different channels.
  • Manual checking of fields and identity.
  • Each bank with its own format and pace.
  • Payment and cost calculated outside the flow.

Limitations

  • Rework caused by inconsistent data.
  • Little visibility of each proposal’s stage.
  • Follow-up depends on memory and spreadsheets.

02 · Mathematical foundation

Confidence calibration and decision threshold

Illustrative example

Each extracted field gets a confidence. Above the threshold the system accepts it on its own; below, it reprocesses or sends it to a person. The ideal threshold balances the cost of reviewing and the cost of being wrong.

Variables

  • τ*optimal confidence threshold
  • crcost of human review of one field
  • cfcost of letting an error through

Objective

Minimize expected cost: reviews performed plus errors that get through.

Constraints

  • Confidence must be calibrated: 90% confidence should be right about 90% of the time.
  • Critical fields may require a higher threshold or always-mandatory review.

Practical example

With c_r/c_f = 0.1 (illustrative value), τ* = 0.90: whatever has confidence above 0.90 passes; the rest goes to the operations desk.

Business implication

The team reviews only what matters, with an explicit rule.

Assumptions and limitations

The costs and the confidence distribution in the tour are illustrative and must be measured.

Bayesian inference over evidence

Proposed architecture

Each document or check updates the assessment of a hypothesis, for example: the data are consistent with the stated identity. It is not a credit score nor a regulated decision.

Variables

  • Hhypothesis being assessed
  • Eobserved evidence
  • P(H)prior belief
  • P(E|H)likelihood of the evidence if H is true
  • P(H|E)updated belief

Objective

Combine evidence in a coherent and traceable way.

Constraints

  • Probabilities between 0 and 1.
  • When combining evidence in sequence, the conditional-independence assumption must be declared.

Practical example

An address mismatch lowers the belief in consistency and sends the case to human review.

Business implication

The system can explain why it asked for review.

Assumptions and limitations

It is not a credit decision, credit risk assessment or legal opinion. Priors and likelihoods need calibration.

Financial mathematics: payment and cost

Illustrative example

For a fixed-rate amortizing loan, the periodic payment results from the amount financed, the rate and the number of payments.

Variables

  • PMTperiodic payment
  • Pprincipal financed
  • rinterest rate per period
  • nnumber of payments

Objective

Compute the payment and total cost to compare offers on equal terms.

Constraints

  • Fixed rate and equal payments.
  • Total cost = PMT × n; fees, insurance and indexers defined by the institution come separately.

Practical example

In the simulation, changing amount, term and rate recalculates the payment and the cost of each simulated offer.

Business implication

Compare offers before any decision, with the same yardstick.

Assumptions and limitations

It ignores fees, insurance and indexers. The example values are simulated.

Policy-driven routing across institutions

Proposed architecture

Rules define which institutions are eligible for the profile and product. Among them, a utility function ranks options according to business criteria.

Variables

  • Eset of eligible institutions
  • ubutility of institution b
  • b*prioritized institution

Objective

Prioritize the best eligible option under business criteria.

Constraints

  • Only institutions that meet the product rules enter.
  • Utility criteria are defined by operations, not by the model.

Practical example

If an institution requires a minimum income the profile does not reach, it leaves the set before the comparison.

Business implication

The proposal goes to whoever can analyze it, in parallel and without trial and error.

Assumptions and limitations

The credit decision remains with the financial institution.

Run the calculation

03 · Technical architecture

Documents

Unstructured input that becomes data.

  • Identification and income documents
  • Property documents
  • Contact and proposal data

Fields with confidence

Each extracted field carries a confidence.

  • Extracted value
  • Field confidence
  • Source in the document

Institution rules

Eligibility and requirements per product.

  • Conditions of each product
  • Eligibility criteria
  • Submission formats

Events

Every step of the process is recorded.

  • Proposal received, sent, answered
  • Pending items
  • Contract and delivery

Real schemas depend on the design with the client and the institutions. The tour and the simulation use fictitious data.

Architecture layers

  1. Intake and documents

    Receiving, organizing and storing per proposal.

    Proposed architecture

  2. Extraction and validation

    OCR, vision, entities, identity and checks.

    Proposed architecture

  3. Confidence and policy

    Decision threshold and human review rules.

    Proposed architecture

  4. Financial engine

    Payment, total cost and offer comparison.

    Proposed architecture

  5. Routing and events

    Parallel submission to institutions and event log.

    Proposed architecture

Phase-one reference architecture. It does not state which component exists in production.

04 · Agentic execution

  • Intake Agent
    Receives the proposal and organizes the documents.
  • Document Intelligence Agent
    Reads documents and extracts fields with confidence.
  • Identity Validation Agent
    Checks the data against the stated identity.
  • Financial Analysis Agent
    Simulates payment, total cost and cash flow.
  • Institution Routing Agent
    Selects eligible institutions and sends in parallel.
  • Follow-up Agent
    Chases pending items and keeps the customer informed.
  • Contract Monitoring Agent
    Tracks the contract until the keys are delivered.
Automation is not regulated approval: agents check, calculate and coordinate. The financial institution decides the credit.

Execution workflow

  1. Document intake

    Documents arrive and are organized per proposal.

    Proposed architecture

  2. OCR and vision

    Text and images become machine-readable data.

    Proposed architecture

  3. Entity extraction

    Names, numbers and dates are extracted with confidence.

    Proposed architecture

  4. Identity resolution

    Records from different sources are linked to the same person.

    Proposed architecture

  5. Validation

    Fields are checked against each other and against rules.

    Proposed architecture

  6. Confidence calibration

    The threshold decides: accept, reprocess or review.

    Proposed architecture

  7. Financial analysis

    Payment, total cost and comparison between offers.

    Proposed architecture

  8. Bank routing

    Policy selects the eligible institutions.

    Proposed architecture

  9. Human approval

    People take over whatever exceeds the policy.

    Proposed architecture

  10. Contract tracking

    Events follow the path to the keys.

    Proposed architecture

05 · Business impact

  • Processing time Not published
    Less waiting between receiving the document and sending the proposal.
  • Document quality Not published
    Inconsistencies are found early, not after submission.
  • Operational throughput Not published
    More proposals handled in parallel by the same team.
  • Manual effort Not published
    Human review concentrates on what falls below the threshold.
  • Follow-up efficiency Not published
    Pending items are chased by event, not by memory.
  • Customer experience Not published
    The customer knows which stage their proposal is in.

These are improvements expected by the phase-one design. The tour cites design parameters, such as at most 200 proposals per analyst, not measured results.

06 · Evaluation & learning

Clave validates and coordinates. The financial institution decides the credit.

Governance and human oversight

Clave validates and coordinates. The financial institution makes the credit decision.

Fields below the confidence threshold go to human review, with the reason recorded.

Every action generates an event; the history makes it possible to rebuild any proposal.

Personal data requires access control and a defined purpose. The security and privacy design must be validated with the client.

Limitations and assumptions

  • The architecture is proposed: this case does not claim production operation.
  • Values, rates and confidence in the simulation are fictitious.
  • The costs c_r and c_f and the confidence distributions must be measured.
  • There is no credit decision, regulated approval or legal opinion in this system.

Future opportunities

  • Measure confidence calibration with real documents and define thresholds per field.
  • Validate submission formats and rules with each institution.
  • Instrument processing time and rework to publish measured results.
  • Validate the security and privacy design with the client.

Open the interactive algorithm tour

The tour walks through confidence thresholds, financial mathematics and events.