Your book — instantiated on the engine that knows its whole future the moment it exists.
Galiprism is the reasoning substrate under your bank. Your chart of accounts becomes machine-readable financial contracts. Every schedule, every regulatory line, every audit answer follows deterministically from the same sealed inputs. Click any product below to watch onboarding, live, against a running engine.
Your product catalogue, mapped once
Four community-bank products, four ACTUS contract types. Click any card to instantiate that product on the engine and watch onboarding pass through: chart-of-accounts mapping, deterministic classification, the engine's schedule of its whole future, and the seal that carries it into audit.
The bank never re-types anything. Once a product line is mapped, every position under it inherits the mapping. Every deviation from the mapping (unknown terms, missing dates) is flagged, never guessed.
What the engine did with that product — line by line
Pick a product above to see the entire onboarding transcript for that line: the chart-of-accounts mapping proposal, the ACTUS instantiation, the deterministic schedule the engine now knows, and the sealed hash of everything that just happened.
Chart of accounts → ACTUS
Your line item
What the engine now holds
Contract instance
A single, versioned, content-addressed object. Same inputs, same object, same hash — forever.
The engine now knows the whole future of this contract
Every scheduled event — coupon, principal, interest accrual, maturity — is derivable from the ACTUS terms alone. The engine writes them out once, hashes the schedule, and refuses to silently regenerate them. If any input changes, the change lives in a successor version with a new hash; the prior version is preserved and remains verifiable.
| Event | Date | Principal | Interest | Balance after |
|---|
The glass box — every determination carries its citation
Sealed onboarding package
The package is not a report; it is the input, the mapping, the schedule, the flags, and the full audit chain — hashed together into one artefact the bank keeps.
Refusals the engine issued
The best evidence the engine is honest is what it refused to answer.
Your general ledger, translated once, valid forever
Every general-ledger account the bank uses today already maps into an ACTUS contract type or a known regulatory line. The engine holds this map; the bank never re-types it. When your auditor asks "what stands behind that balance?", the answer is a single hash.
| Your GL line | Product family | ACTUS type | Regulatory home |
|---|---|---|---|
| 1010 · Demand deposits | Transaction accounts | PAM (zero-rate) | FFIEC RC-E · non-interest-bearing |
| 1150 · Time deposits < 100k | Retail CD, 3-month | PAM · single coupon | FFIEC RC-E · time deposits |
| 1240 · Residential mortgages | 30-year fixed | ANN · annuity | FFIEC RC-C.1.a · 1-4 family |
| 1360 · Commercial & industrial loans | Line of credit | PAM · variable drawn | FFIEC RC-C.1.d · C&I |
| 1470 · Consumer loans | Auto instalment | ANN · annuity | FFIEC RC-C.1.e.1 · autos |
| 3010 · Common equity tier 1 | Capital | — (capital component) | Basel III CET1 / FFIEC RC-R |
This is a representative slice. Onboarding a real community bank walks the full CoA; unmapped lines are surfaced (never silently classified), and each new mapping the bank confirms enters a hash-chained ledger — reviewable by any regulator with the seal.
What you just watched
A bank picked a product, the engine instantiated the contract, produced its whole future as a deterministic schedule, sealed everything with a hash, and let an independent verifier re-derive the answer with duplicated maths. The verifier is not a second opinion of the engine — it is a bit-identical re-computation from the same inputs. If the numbers disagree, the seal fails.
Everything above is running on the Galiprism engine at localhost. The same call surface is what a hosted tenancy or a sealed sovereign instance would present. Nothing on this page is a mock.