COM decides what must be proven about a business, not which forms to collect. This page is both an explainer and the live reference — everything renders from the real model data.
New here? Read the short story just below, then skim the 💡 notes at the top of each section — they say what each part means in plain terms. The tables and explorers underneath are the full reference; you can ignore them until you need them. Jargon? See the glossary.
The whole model in one story
A business applies. Marea Pagos, a payments company in Mexico, wants an account. IRIS scores its risk from a short questionnaire — country, industry, expected volume. Mexico plus $300k/month lands it at Moderate risk.
Risk decides the checklist. Moderate risk means ~13 things must be proven — the company exists, who owns it, where it operates, where the money comes from. Riskier applicants must prove more; that's the whole levelling system.
Documents tick items off. Marea uploads its Acta Constitutiva — the registry knows that in Mexico this single document proves both formation and ownership. The RFC certificate proves tax registration. Each upload is auto-classified and matched.
What's left is the ask. Two items remain unproven (source of funds, signatory authority). Marea gets a link listing exactly those two — nothing more. That's a gap, and closing gaps fast is what "onboarding speed" means here.
Partners add their asks. The banking partner used for USD payouts has its own extra requirements. Those stack on top of our floor — partners can add, never subtract.
Approval isn't the end. The moment Marea is live, ITAM starts watching: 90 patterns over its transactions. Three withdrawals in a day just under the reporting threshold? Alert. Sanctions hit? The transfer freezes for a compliance officer. Monitoring findings can reopen onboarding asks — the loop never fully closes.
💡 In plain terms: when a business applies, the system builds a checklist of what must be proven about them. Documents tick items off. Whatever is still unticked is exactly what we ask the customer for — nothing more, nothing less.
Four primitives — proof categories (the stable ontology), documents (local artifacts), risk tiers (how much evidence is enough), and provider acceptance (per-rail add-ons). The engine is a pure function evaluated on every read:
ORR scoring over jurisdiction, industry (NAICS), volume, and modifiers → a numeric score.
2 · Band to tier
Score bands map to LowModerateHigh — the Infinite floor for that tier.
3 · Provider overlay
Each requested rail's provider adds its own required proofs. Add-only — never subtracts from the floor.
4 · Subtract satisfied
Uploaded documents resolve to proof satisfactions; what remains outstanding = the gaps surfaced to the customer.
Proof categories
💡 The master checklist items. Every requirement anywhere in the system is one of these ~30 plain statements — "the company really exists", "we know who owns it", "we know where its money comes from". Countries and partners never add new kinds of items; they only change which documents can tick them.
The canonical ontology — every requirement anywhere in the system is one of these. Filter by tier or search. Each shows its satisfaction sources (satisfiedBy).
Explore all 30 proof categories
Risk levelling (ORR)
💡 Riskier businesses must prove more. A questionnaire-style score (country, industry, volume…) sorts each applicant into Low / Moderate / High — and that tier decides how long their checklist is.
Onboarding Risk Rating: 11 scored fields, max score 30, summed across four domains (geography, ownership & control, products/services, expected activity). Geography fields classify via the country risk tiers; NAICS is inferred from business description + website.
Score → tier bands
Low 0–12 · Moderate 13–19 · High 20–30. RDD is unreachable by score alone — it fires only via a CRITICAL trigger.
Trigger aggregation
Weights: LOW 1 · MODERATE 2 · HIGH 3 · CRITICAL 5. Any CRITICAL → rdd; any HIGH → high; cumulative ≥ 4 (or any trigger) → moderate.
Final rating
final = max(trigger_tier, orr_tier) on low < moderate < high < rdd. Country gates: 17 prohibited (blocked at creation) · 11 controlled (CCO sign-off) · 66 restricted · 10 offshore centers (always +GOOD_STANDING_CERT & REGISTERED_AGENT_LETTER, HIGH trigger).
Proposed — ORR v3 (0–100). The max-30 scale is coarse (one answer can jump a whole tier), doesn't extend without re-banding, and clashes with ITAM's 0–100 vocabulary. v3 moves to weighted, normalized dimensions — geography 25 · ownership & control 25 · products/services 30 · expected activity 20 — so new factors (PSP program quality, corridor exposure) slot inside a dimension and the tier bands never move. Strawman bands: Low <40 · Moderate 40–65 · High >66, to be fixed by backtesting the full book. RDD stays trigger-only, now as explicit policy (no more "≥31 of 30"). Externally we keep reporting tiers, not numbers. Status: draft (orr-scoring.v3-draft.json), pending dual-score backtest + calibration sign-off.
Explore the full scoring spec & country tier lists
Risk triggers
💡 Specific red flags that raise the risk level no matter what the score says — a sanctioned country, an unlicensed money business, bearer shares. One critical flag is enough to force the strictest handling.
Discrete conditions that escalate a case — each carries a weight feeding the ORR score or forcing tier bumps / EDD additions.
Explore all 64 triggers
Trigger
Weight
Condition / description
Satisfaction criteria
💡 The rules for when a document actually counts: is it the right document for that country, is it recent enough, and has anyone verified it? Evidence gets stronger over time (collected → validated → verified) and can expire.
How evidence satisfies a proof category: the 4-arity match satisfies(doc, proof, entityType, country), evidence strength, freshness windows, and the confidence ratchet.
Explore the satisfaction rules — matching, strength, freshness, ratchet
Onboarding mappings per provider
💡 Each banking / payout partner has extra asks on top of our own checklist. This section shows exactly what each partner adds, so "why are we being asked for this?" always has a one-line answer.
The current provider set and what each requires on top of the Infinite floor — CDD baseline docs, EDD/RDD additions, person rules, and conditional requirements. Providers flagged dynamic expose a runtime requirements endpoint the adapter maps into proof categories.
Explore all 7 partner requirement sets
Per-country document registries
💡 Every country calls its paperwork something different. This registry maps local documents — Brazil's Contrato Social, Mexico's Acta Constitutiva, a UK Companies House extract — to the checklist items they prove, and how strongly.
The full registry: which local documents are accepted in each jurisdiction, which proofs each satisfies, at what strength, with what freshness.
Explore the registry — 650 documents across 61 jurisdictions
Local document
Type
Issuing authority
Proves
Strength
Freshness
Applies to
ITAM — Infinite Transaction and Activity Monitoring
💡 Onboarding ends; watching begins. These are the live patterns we look for in real activity — structuring, sanctions exposure, odd velocity — and what happens when one fires: an alert, a paused transfer, or a compliance-officer hold.
The ongoing-monitoring half of the model. As Infinite shifts to a reliance model — trusting direct fintech customers' onboarding against an agreed document set — assurance weight moves here: scenario-based monitoring across three planes (PSP aggregate · sub-fintech program · end-user flow), plus corridor and jurisdiction rules.
Strategy note: the COM's nested_fi_or_payable_through CRITICAL trigger reflects the inherited posture where nesting was near-prohibited. Under Infinite's PSP-first, direct-to-bank model, nested programs are the product — that trigger becomes a managed-program pathway (downstream due-diligence obligations + ITAM supervision), not a block.
How the engine decides — pipeline, tiers, decay, thresholds, governance
Decision pipeline
Event → provider checks (Chainalysis wallet · name screening · Notabene TR · DataVisor rules) → hard block if wallet risk severe or sanctions match ≥ 80 → corridor enrichment → signals → risk state → decision: PASS · ALERT · HOLD · HOLD_CO. Severity 0–100 per scenario.
Tier & monitoring level
sanctions ≥ 80 → critical · any dimension ≥ 80 → high · ≥ 65 or two ≥ 50 → moderate · else low. Maps to monitoring: standard / enhanced / intensive. Six dimensions incl. sanctions_exposure, structuring_risk, behavioral_anomaly.
US (FinCEN, MSB): structuring $10k · band $8,000–9,999 · TR $3k · SAR 30d / CTR 15d · retain 5y MX (CNBV/UIF): MXN 150k · band 120–149,999 · TR MXN 20k · ROS/AVISO 24h · retain 10y BR (BACEN/COAF, bank JV): BRL 50k · band 35–49,999 · SISCOAF within month · retain 10y
Governance & rollout
15 of 90 scenarios are V1-approved (all sanctions-critical, sub-CTR structuring, TR, KYB-state); the rest are calibrated Phase 2/3 stubs. Quarterly calibration · sanctions scenarios reviewed every 30d · threshold changes need 2 approvers + backtest + 7-day review · 7-year immutable audit ledger. Provider load: DataVisor 47 · onboarding feed 19 · Chainalysis 12 · OFAC 7 · Notabene 4 · bank JV 1.
COM → ITAM handoff: onboarding emits a CustomerRiskProfile (tier, ORR score, declared volume/countries, fired triggers, review cycle 24/18/12 months by tier). Declared baselines feed NR-05 (150% volume deviation) and RIO-01 (velocity); CMP-02 closes the loop by querying outstanding proofs and queuing re-collection — monitoring findings pull customers back into onboarding, which is exactly the reliance-model control loop.
Explore all 90 scenarios, corridors & monitoring governance
Scenario library
Corridors
Jurisdictions & providers
Governance
Document-classification prompts
💡 The exact instructions our AI uses to read, classify, and sanity-check uploaded documents. Published here for transparency — this is how an Acta Constitutiva gets recognized as one.
The prompts used to classify per-country documents (production pipeline, evals, virtual-address detection). Verbatim from the codebase.
Explore the 14 production prompts
Glossary
The dozen terms that unlock everything above.
Proof category
One item on the master checklist — an abstract thing that must be proven ("ownership is documented"). ~30 exist; everything maps to them.
Tier (Low / Moderate / High)
How much evidence is enough. Internally CDD / EDD / RDD. Higher tier = longer checklist, more frequent reviews.
Gap
A required proof with no valid evidence yet. Gaps are literally what we ask customers for.
Satisfaction
A record that a proof is met — by which document, how strongly, and until when.
Confidence ratchet
Evidence quality only moves up: collected (we have it) → validated (a data source confirms it) → verified (a human or ID check confirmed it).
Trigger
A discrete red flag with a weight. Enough weight — or one critical flag — escalates the tier regardless of score.
ORR
Onboarding Risk Rating — the questionnaire-style score (max 30) that sets the initial tier.
Floor vs overlay
The floor is Infinite's own minimum checklist per tier. Partner (provider) requirements stack on top — they can add, never subtract.
Corridor
A directional currency route (MXN→USD). Corridors carry their own risk level and reporting rules.
Scenario
One monitored pattern in ITAM ("3+ withdrawals just under the reporting threshold in 24h"), with a severity and an action.
HOLD / HOLD_CO
Scenario actions: pause the transaction for review — HOLD_CO requires a compliance officer to release it.
UBO
Ultimate beneficial owner — a person owning ≥25% or otherwise controlling the business. Chains of holding companies are traced to real people.
RFI
Request for information — the follow-up ask when something is missing or unclear.
Reliance
Trusting a fintech customer's own onboarding of its users against an agreed doc set — with monitoring, sampling, and the right to revoke.
Infinite Risk Information System — Canonical Onboarding Model · rendered from live model data (@infinite/com).