Amlok
The idea in brief.
Embedded finance brings financial decisions closer to the systems where business happens. It also creates several observations of the same event. The challenge is to preserve their relationships, resolve differences, and show what remains unknown rather than equating more integrations with more independent evidence. [1]
- Count economic events, not the number of systems reporting them.
- Represent permission, freshness, and coverage alongside every derived financial view.
- Keep observed facts, calculated measures, and model interpretations distinguishable in the response.
The architecture and worked settlement example are proposed methods. The FinQA measurement is a published document-retrieval result; it is not an evaluation of an embedded-finance integration or an API’s credit decisions.
Integration is the beginning of the evidence chain
A successful connection establishes access to a source. It does not establish that every relevant account is present, that historical coverage is complete, or that records reconcile with another system. A merchant may connect one processor but use several. A bank connection may omit a facility held elsewhere. An accounting export may contain accrual entries with no cash movement.
Treat coverage as part of the analytical result. Record the authorized source, accounts included, earliest and latest observations, refresh time, and known gaps. Derived measures should identify the exact window and inputs they used. If coverage changes, a comparison may need to be restated rather than interpreted as business growth or contraction. [1][2]
A useful API contract should make these distinctions consumable: source observations, normalized facts, linked economic events, calculated measures, and review flags. These are recommendations for response design, not undocumented promises that every Amlok endpoint already exposes the same fields.
A response should carry its evidence
- 01Authorized sources
Scope, freshness, coverage, and connection state.
- 02Economic events
Match observations; retain conflicts and timing.
- 03Derived measures
Versioned formulas and explicit input windows.
- 04Review context
Evidence links, uncertainty, and next questions.
Reconcile before aggregating
Imagine a platform records CAD 10,000 in captured sales. The processor reports CAD 500 in refunds, CAD 300 in fees, and a CAD 200 reserve addition. The net payout is CAD 9,000. A bank account then records that same CAD 9,000 deposit. The economic sale remains CAD 10,000 gross; settlement is CAD 9,000. Adding all three positive observations would incorrectly suggest CAD 28,000 in separate inflows.
A matching rule should use identifiers where available, then compatible amounts, dates, and counterparties. Timing windows need to reflect actual settlement conventions. Uncertain matches should remain candidates, not silently accepted links. One payout can cover many transactions, so the evidence graph must support aggregation relationships as well as one-to-one matches.
For analysis, keep the accounting question explicit. Revenue recognition, gross merchandise volume, processor settlement, and unrestricted bank cash are different measures. Reconciliation explains their differences; it should not erase those differences to produce a single convenient number. [3]
| Observation | Amount | How it contributes |
|---|---|---|
| Captured platform sales | 10,000 | Gross activity for this event set |
| Refunds + fees + reserve addition | 1,000 | Adjustments to settlement |
| Processor payout | 9,000 | Net settlement, not additional sales |
| Matched bank deposit | 9,000 | Confirmation of the same payout |
Measure whether the evidence was found
Amlok’s FinQA experiment makes a useful architectural point. BM25 retrieves all annotated support within five candidates for 61.81% of 1,147 held-out questions. The remaining 38.19% is the calculated share with incomplete evidence at that cutoff. This does not measure answer correctness, nor does it measure connected-account completeness. [4][5]
The general design implication is to evaluate the evidence stage independently. A downstream model cannot reliably justify a calculation using a table row it never received. A plausible-looking answer can hide that failure. Coverage checks, missing-input states, and source inspection therefore deserve their own tests rather than being bundled into a single end-to-end score.
For an integration, analogous tests should use its own ground truth: expected accounts, reconciled events, known statement periods, and source availability. An improvement on a financial-report benchmark does not transfer automatically to payment reconciliation. The bridge between tasks must be tested.
A useful answer starts with sufficient evidence
View figure data
| Measure | Value |
|---|---|
| All annotated evidence retrieved | 61.81% |
| Incomplete at five candidates | 38.19% |
Design for interrupted connections
An expired authorization, a source outage, and an account with no new activity can look similar if every failure becomes an empty list. Preserve distinct states. A consumer of the API needs to know whether there are no records, whether records could not be fetched, or whether the source is no longer in scope.
Use an explicit freshness policy for each decision. Historical statements may remain useful for one analysis while being too stale for another. Retain the last successful observation without presenting it as newly observed. When a source recovers, reconcile backfilled events and avoid interpreting a batch arrival as a sudden burst of economic activity.
Corrections also need history. If a processor amends a transaction or an entity match is reversed, derived measures may change. Keep both the prior result and the revised version with the reason for revision. This makes an institutional review reproducible and gives the product team a concrete failure mode to improve. [2][6]
Evaluate the platform boundary
A pilot should include realistic missingness and integration failures, not just fully connected demonstration accounts. Measure reconciliation accuracy against reviewed records, source-coverage completeness, duplicate handling, correction behaviour, and the ability to trace a result back to its inputs.
For predictive research, hold out entire platforms or institutions when transfer is the claim being tested. A model may learn platform-specific bookkeeping conventions that do not generalize. Separate coverage effects from model effects: a richer source set and a better algorithm are different interventions. [7]
For operational governance, assign ownership of authorization, data correction, analytical interpretation, and the final financial decision. NIST’s voluntary AI risk-management framework offers a general governance reference, but the specific controls and their effectiveness must be demonstrated in the deployed workflow. [8]
Sources & methodology.
Figures identify their population, period, and units. Scenarios marked illustrative are Amlok calculations using stated assumptions, not observed customer outcomes.
- 1Embedded finance workflowsAmlok research and product documentation
Data coverage, consent, platform context, and economic-event reconciliation.
- 2Financial record modelAmlok research and product documentation
Proposed representation of source, entity, amount, period, event time, and knowledge time.
- 3Financial analysis and evidenceAmlok research and product documentation
Definitions, reconciliation, and analytical methods; implementation guidance rather than measured portfolio performance.
- 4Real-data training and benchmark resultsAmlok research and product documentation
Research release 0.3. Separate SBA charge-off and FinQA evidence-retrieval experiments; self-reported reproducible research, not independent product validation.
- 5FinQA retrieval result manifestAmlok · downloadable JSON
Machine-readable lexical retrieval results; paired uncertainty uses source-filename clusters.
- 6Monitoring and change detectionAmlok research and product documentation
Proposed monitoring design, observation windows, baselines, and evaluation requirements.
- 7Evaluation designAmlok research and product documentation
Evaluation protocols and research objectives. A specified protocol is not evidence that an experiment has been completed.
- 8Artificial Intelligence Risk Management Framework 1.0NIST · January 2023
Voluntary risk-management framework; references to it do not imply certification or a completed conformity assessment.
