Contact

Case · Clave · Financial and Document Intelligence

From fragmented financial workflows to intelligent credit operations.

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.

Proposed architectureIllustrative exampleNot published
Open the interactive tour

01

Executive summary

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.

Business impact

This case does not publish measured results. The relationships below are design hypotheses, not numbers.

02

Business context

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.

03

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.

04

Current process and limitations

Before

  • 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.

05

Data 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.

06

Mathematical formulation

Confidence calibration and decision threshold

Illustrative example · Illustrative parameters

Business interpretation

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
  • c_rcost of human review of one field
  • c_fcost of letting an error through

Objective function

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 · Illustrative parameters

Business interpretation

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 function

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 · Illustrative parameters

Business interpretation

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 function

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 · Illustrative parameters

Business interpretation

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
  • u_butility of institution b
  • b*prioritized institution

Objective function

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.

07

AI and agent architecture

  • Intake AgentReceives the proposal and organizes the documents.
  • Document Intelligence AgentReads documents and extracts fields with confidence.
  • Identity Validation AgentChecks the data against the stated identity.
  • Financial Analysis AgentSimulates payment, total cost and cash flow.
  • Institution Routing AgentSelects eligible institutions and sends in parallel.
  • Follow-up AgentChases pending items and keeps the customer informed.
  • Contract Monitoring AgentTracks the contract until the keys are delivered.

Policy layer

Automation is not regulated approval: agents check, calculate and coordinate. The financial institution decides the credit.

08

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

09

Interactive demonstration

Simulated

A synthetic proposal, from document to next action

Values, rates, rules and confidence are fictitious. The demonstration shows the logic: extract fields, measure confidence, review, simulate conditions and identify eligible institutions. There is no credit decision.

10

Governance and human oversight

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

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.

11

Operational outcomes

  • Processing timeLess waiting between receiving the document and sending the proposal.Not published
  • Document qualityInconsistencies are found early, not after submission.Not published
  • Operational throughputMore proposals handled in parallel by the same team.Not published
  • Manual effortHuman review concentrates on what falls below the threshold.Not published
  • Follow-up efficiencyPending items are chased by event, not by memory.Not published
  • Customer experienceThe customer knows which stage their proposal is in.Not published

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.

12

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.

13

Technical architecture

  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.

14

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.

Discuss a challenge in your operation

Tell us the process you want to improve. We reply by the email you provide.

Discuss a challenge in your operation