One platform read four ways: the logical model of cores, workflows and the AI governance plane; the deployment shapes institutions choose between; the integration surface upstream and downstream systems plug into; and the security and trust boundary that holds it together. The architecture reference behind the use cases — for the CIOs, Heads of Engineering and VP Architecture teams scoping a CoreFi deployment.
CoreFi’s logical model is three horizontal layers and one vertical control plane. A cloud-native real-time core sits at the base — ledger, accounts, product engine, payments and reporting. The lifecycle workflow layer above it turns the core’s primitives into onboarding, lending, servicing and operations journeys. Five agent roles — Credit, Onboarding, Service, Compliance and Operations — operate those workflows. None of them touch the ledger directly: every action passes through the AI Governance plane that enforces scoped identity, policy gates, human approvals and a case-level audit record.
Real-time ledger, accounts, wallets, product engine, payments and reporting. The system of record every workflow and agent posts into — designed to support institutional throughput, jurisdictional residency and a durable audit trail.
Onboarding, lending, servicing, operations and compliance as first-class workflows inside the platform — not afterthoughts bolted on via third-party orchestration. Each workflow declares its own policy and approval shape.
Five operator roles — Credit, Onboarding, Service, Compliance, Operations — running the same Sense → Plan → Check → Act → Record → Escalate → Learn lifecycle. Roles differ by scope, not by mechanism.
The control surface running alongside every layer: scoped identity per caller (human, system or agent), policy gates evaluated before any side effect, approval routing into reviewer queues, and an append-only case-level audit record keyed to the case and the model version.
CoreFi runs as one platform across three deployment shapes. The shape determines who operates the infrastructure, where customer data lives and how much of the control plane the institution owns end-to-end. The application surface, the workflow layer and the governance plane do not change between shapes — only the perimeter does.
CoreFi-operated cloud, shared infrastructure, shared upgrade cadence. Fastest go-live and the lowest operational footprint on the institution side. Regional residency is configured per tenant and available on request.
Dedicated CoreFi-managed deployment in a chosen region: dedicated database, dedicated network perimeter, dedicated upgrade window. Designed to support institutions with stricter isolation, change-control and continuity requirements.
CoreFi deployed inside the institution’s own cloud account (AWS, Azure, GCP) or sovereign-cloud region. The institution controls the perimeter; CoreFi operates the platform on it. Available on request, with a joint operating model agreed up front.
Banks and digital lenders do not run CoreFi in isolation: it sits between channels, partners, vendors and downstream systems of record. The integration surface exposes five complementary mechanisms — REST APIs for synchronous calls, event streams for asynchronous propagation, outbound webhooks for ecosystem partners, file-import pipelines for batch sources, and SDKs for in-channel embedding. Each mechanism inherits the same identity, policy and audit model as the rest of the platform.
Versioned, scope-tokenised endpoints across core, lending, onboarding and ledger surfaces. Every call is identified, policy-checked and audited inside the same case record an agent or operator would generate.
Outbound business events across account, transaction, application and case lifecycles. Consumers subscribe per topic and replay from a durable log — designed to support downstream analytics, regulatory reporting and customer-system propagation.
Signed HTTP callbacks for partner platforms — KYC providers, payment rails, scoring engines — to push state changes back into CoreFi. Retry policy, signature verification and idempotency are first-class parts of the surface.
Batch pipelines for legacy back-office feeds, regulator extracts, bureau files and bulk operational uploads. Each file is treated as a case: validated, audited and routed to operator approval where policy requires it.
Web, mobile and in-app SDKs for embedding CoreFi journeys inside the institution’s channels — without re-implementing identity, policy or audit on top.
API reference, integration patterns, sandbox tenancy and migration recipes live in the Developer Center. Architecture teams typically start there for the surface-level shape before scoping a deployment.
Security at the architecture layer is not a checklist of certificates; it is a boundary diagram. The institution owns the customer relationship and the regulated perimeter. CoreFi operates the platform within it. The AI Governance plane is the shared control surface that both sides see: scoped identity for every operator (human, system or agent), policy gates evaluated before any side effect, encryption in transit and at rest, audit records pinned to the case and the model version, and data-residency boundaries that follow the deployment shape.
Customer data and audit records pinned to a chosen jurisdiction — EU-resident by default, LATAM and other regions available on request. Backups and processing follow the same residency boundary as the primary record.
One append-only record per workflow: trigger, retrieved data, model and prompt version, plan, policy outcome, API calls, side effects, escalations, human decisions, final state — designed to support internal, external and supervisory review. Cryptographic hash-chain verification is wired today for AI Assistant tool calls; per-workflow extension is on the roadmap.
Policy gates evaluated on every step before any side effect: role permissions, customer consent, transaction and exposure limits, AML and sanctions filters, model-output guardrails, jurisdictional restrictions. Failed checks stop the workflow.
Encryption in transit and at rest across customer data, audit records and inter-service traffic. Key management is integrated with the deployment shape — institution-managed keys available on request for single-tenant and customer-cloud deployments.
Every caller — human operator, partner system or AI agent — gets a scoped identity with role, environment and limit attached. The same identity carries through API, event and webhook surfaces.
Security posture, sub-processor list, third-party attestations where they apply and supporting artefacts are tracked in the Trust Center. Architecture teams under NDA can request the full pack as part of a scoping conversation — available on request.
Most CoreFi deployments run alongside an existing core for a defined coexistence window: a strangler-fig boundary, a synchronisation path, an event-based view of the legacy system and a migration shape sized to the institution’s appetite. The coexistence story is its own architectural conversation — too big for a section on this page. Walk the dedicated Migration & Coexistence reference for the strangler-fig pattern, the four phases (Discovery → Shadow → Parallel → Cutover) and the risk envelope per workflow. The five adoption paths on the Implementation page cover the same ground at the deployment level.
A 60-minute working session with CoreFi’s architecture team: the four diagrams against your environment, a sketch of the deployment shape that fits your perimeter, and an integration surface mapped to your upstream and downstream systems.