Architecture
One runtime, under every action.
Run the whole lending stack on KrimOS, or layer it onto the systems you keep — origination to collections, every action validated.
The runtime
Run the whole stack, or layer onto yours.
Module by module
The machinery, and why each one earns its place.
The runtime layer is named Kendra. It is realised as eight engineering modules. Each does one job, and together they are why validated AI can act in regulated work.
Orchestration
Krim-Core
Routes each request to the right co-worker and drives the workflow to completion, with retries, fallbacks and human-in-the-loop built in.
Why it matters
Work lands with the right co-worker and runs to the end, even when a system drops mid-flow.
Scheduler
Krim-Karya
Owns when work runs: timed tasks, deadlines and contact-hour windows, so every action fires only when it’s allowed.
Why it matters
Nothing fires outside contact hours or ahead of a deadline, with no one watching the clock.
Knowledge base
Krim-Fabric
Each market’s rules, your own policies and the shared pattern library, in one place every co-worker reads from.
Why it matters
Every co-worker reads one current rulebook, so the floor never acts on a stale copy.
Policy engine
Krim-Govern
A seven-level policy hierarchy of law, regulator guidance, house rules and guardrails, enforced per tenant.
Why it matters
When a rule changes, every co-worker inherits it at once, with no release cycle in between.
Validator
Krim-Nyāya
A pre-execution pipeline of 33 validators that gates every action before it fires.
Why it matters
An action that can’t clear policy is stopped before it fires, and sent to a person with the rule that caught it.
Learning
Krim-Learn
Ten learning loops that turn recorded outcomes into sharper decisions across the workforce.
Why it matters
The operation reads its own outcomes, so by its second year it runs materially sharper than the day it went live.
Metered record
Krim-Ledger
Logs every action immutably and meters it in Krim Work Units, serving audit and billing from one source.
Why it matters
Every action is provable from one record, so an inspection answer is assembled in minutes.
Telemetry
Krim-Sense
Metrics, logs and alerts across the stack, feeding Kupa and monitoring.
Why it matters
A stall, a spike or a drift surfaces while you can still act on it.
The substrate
What the co-workers stand on.
Beneath the modules sits a shared substrate: the memory the workforce thinks with, the orchestration that keeps long work durable, and the single domain model they all speak.
Shared memory
Four tiers (working, short-term, long-term, episodic), shared across the workforce, so a pattern one co-worker learns is available to the rest without retraining.
Durable orchestration
Long-running workflows run on Temporal-class orchestration in Krim-Core, durable across crashes and deploys, with automatic retries, saga-pattern rollbacks, event sourcing and deterministic replay for incident investigation.
Shared domain model
One model of 15 core entities: Tenant, Account, Borrower, Loan, Interaction, Decision, PaymentPlan, Policy, ComplianceEvent, AuditLog and more. It is the common language every co-worker reads from and writes to.
The integration fabric
It fits the stack you already run.
40+ connectors span core banking, loan origination and servicing, CRM, telephony, messaging, payments, credit bureaus and document management. Event-driven where systems allow, with batch and polling fallback for legacy. One common behaviour handles auth, field mapping, retries, sync and observability.
When you keep your existing systems, they stay the source of truth and KrimOS writes back only on validated channels. When KrimOS is the stack, the same gate holds and the source of truth is its own immutable record.
Two paths in
- Event + stream: webhooks and streaming for systems that emit changes in real time.
- Batch + poll: scheduled extracts and polling for legacy systems that don’t.
- Validated write-back: nothing returns to your systems until it has cleared the gate.
One architecture, every geography
The same runtime, sovereign in every market.
KrimOS runs the same architecture in every market it serves. Only Krim-Fabric’s rule set changes. Each region runs self-contained behind its own walls, the local law already loaded, so one runtime, audit trail and governance carry from market to market unchanged.
Common questions
What engineers ask first.
Does KrimOS replace our core banking, LOS or CRM?
Your choice. KrimOS is a complete lending stack of its own — origination, underwriting, servicing and collections — so you can run the operation on it end to end. Or keep the systems you have: KrimOS layers on top, reading from them and writing back only on validated channels, so you can start with nothing to tear out and run as much on KrimOS as you choose.
How does KrimOS connect to our existing stack?
Through an integration fabric of 40+ connectors across core banking, origination and servicing, CRM, telephony, messaging, payments, credit bureaus and document management. It is event-driven where systems allow, with batch and polling fallback for legacy.
Does the same architecture run in every market?
Yes. One architecture runs in every market; only Krim-Fabric’s per-jurisdiction rule set changes. Each region runs sovereign within its own perimeter, with the jurisdiction’s law already encoded.
See it slot into your architecture.
A two-week technical deep-dive covers architecture, security and integration, then a scoped pilot follows on ring-fenced data.