One API surface across the core ledger, lending, onboarding, payments, tokenization and the AI workflow control plane. OAuth 2.0 and JWT, scoped permissions, signed webhooks, and a tool-calling layer your agents can talk to under the same governance as your operators.
CoreFi exposes the same primitives a bank operates on — accounts, ledger entries, customers, loans, payments, tokens, KYC cases, AI workflows — through a coherent REST + webhook surface. You can run a digital lender on top, modernize one banking journey alongside a legacy core, or wire AI agents into existing operations under the bank's permission and audit model.
The platform is the same for human integrators and AI agents: every call is authenticated, scoped to a permission set, evaluated against policy, executed through the core, and recorded in the audit log. There is no separate "AI lane" that bypasses controls.
A reference portal and official SDKs are in active development. Until they are public, sandbox tenants get a versioned OpenAPI specification and integration guides delivered through your account.
Public OpenAPI portal covering accounts, ledger, customers, lending, onboarding, payments, tokens, AI workflows and webhooks. Today, the OpenAPI specification is shared with sandbox tenants on request — no public endpoint examples yet.
Typed client for Node.js and browser integrations, generated from the OpenAPI spec. Targeting first published release alongside the public reference portal.
Pythonic client for backend services, data pipelines and agent runtimes. Generated from the same OpenAPI spec as the TypeScript SDK so contracts stay in lock-step.
JVM client for institutions standardised on Java/Kotlin. Surfaces the same resources, scopes and pagination model as the other SDKs.
Versioned OpenAPI 3.1 document is shared with sandbox tenants under NDA. It is the source of truth for the SDKs above and for any internal client generation you want to do today.
Importable collection for ad-hoc exploration of the sandbox. Will track the same versions as the OpenAPI specification.
CoreFi sandboxes are full tenants — your own ledger, your own accounts, your own webhook endpoint, your own scoped credentials — running on the same code path as production, with synthetic data and no real value flow.
Every CoreFi request is authenticated. The platform issues short-lived JWT access tokens via OAuth 2.0; the same token model covers human operators, server-to-server services and AI agent runtimes.
Server-to-server flow for backend services and scheduled jobs. The client authenticates with its credentials and receives a short-lived JWT access token bound to a fixed scope set.
User-facing flow for operator dashboards and customer-facing channels. Returns an access token plus a refresh token; the access token carries the user's role and the session's scope set.
Federated flow for trusted services that already authenticate users — including AI agent runtimes. The caller presents a signed assertion; CoreFi exchanges it for an access token bound to the agent's scope and the principal it is acting on behalf of.
Tokens are validated on every request. Signing keys are rotated and published through a JWKS endpoint. Tokens carry the principal, the scope set, the tenant, the issuance time and a unique identifier so every call can be tied back to a specific session in the audit log.
Permissions are explicit and layered. A token cannot call an API it has not been scoped to. Beyond scopes, the bank's policy gates evaluate every action before it touches the ledger.
Each token carries a fixed scope set such as accounts.read, ledger.write, kyc.cases.review, workflows.run. Scopes are granted at the client level and can be narrowed further per session. Calls outside the scope set are rejected before reaching the resource.
Roles bundle scopes for human operators (reviewer, underwriter, treasurer, MLRO, admin) and for service principals. Roles are tenant-configurable; a bank can change what "reviewer" can do without redeploying any client.
Even when scopes pass, the platform evaluates each action against configurable policy: transaction limits, customer-segment rules, jurisdictional restrictions, AML and sanctions checks, model-output guardrails. Failed gates either block or escalate to a human approver.
Tokens can carry an acting principal — the human or system that delegated the action — distinct from the authenticated client. The audit log records both, so an agent acting on behalf of an operator stays attributable end-to-end.
Every token is bound to a single tenant. Cross-tenant calls are rejected at the token layer; multi-tenant integrations request one client per tenant and switch the token, never the URL.
Every authenticated call writes a record: principal, on-behalf-of, scope set, gate decisions, side effects on the core, and any human approvals along the way. Exportable for internal review, external audit and supervisory requests.
CoreFi pushes platform events to your endpoint as soon as they are committed. Every payload is signed; you verify the signature before you act. Delivery is at-least-once with monotonic sequencing per resource so you can deduplicate safely.
Account opened, status changed, balance updated, journal entry posted, statement closed. The same events that drive the operator dashboards are available to your services.
Application received, decisioned, funded, repaid, written off; collateral changes; collection events. Tied to the underlying credit memo so your CRM stays in sync with the core.
Case created, escalated, decisioned, periodic-review due. Carry the decision rationale and a reference to the structured evidence packet for downstream review systems.
Payment received, released, returned, settled, reconciled. Enough metadata to drive a customer notification or a treasury reconciliation without an additional round trip.
Token issued, transferred, redeemed, frozen; custody key events; reserve attestation milestones. Useful where tokenization sits next to the core ledger as a separate system of record.
Workflow started, plan proposed, policy gate decision, action executed, escalation raised, human decision recorded, workflow closed. Same audit-grade detail as the in-product reviewer view.
CoreFi publishes a catalog of tools — typed function definitions an AI agent can call — that map onto the same REST surface, scopes and policy gates as the rest of the platform. Whatever your agent is allowed to do, an operator with the same scope set could do too. Nothing more.
Each tool is a typed contract: name, description, input schema, output schema, required scopes, policy gates that apply, and the human-approval shape if any. The catalog is queryable so an agent can discover only the tools its scope set allows.
An agent runtime authenticates as a service principal through the JWT bearer flow, optionally on behalf of an operator. Its token carries the agent's scope set; tools outside that set are not even visible.
Before a tool is executed, the platform runs the same lifecycle as the AI Workflows control plane: the agent's proposed call is validated, evaluated against policy, executed through the core, and recorded. Failed gates stop the call or escalate.
Tools whose underlying action requires human approval do not block the agent runtime. The platform issues a structured "pending" result; once a human approves in the reviewer dashboard, the workflow resumes from the same step.
The catalog is published as JSON Schema and as native tool definitions for major providers (OpenAI / Anthropic / Gemini-style function calling). Swap the model or run several side-by-side without changing the contract.
Every tool call is written to the same immutable workflow record as a human action: who called it, on whose behalf, with what input, which gates evaluated to what, and what changed in the core. Regulators get one record per case.
Production tenants get visibility into platform health and an audit-friendly history of every change to the API surface. The public-facing surfaces below are being built out alongside the reference portal.
Public uptime and incident history for the platform. Until the public page is live, sandbox and production tenants receive incident notifications through their account contact and through the operator dashboard.
Versioned changelog for the API surface, SDKs and AI workflow control plane. Until the public changelog is live, sandbox tenants receive release notes alongside the OpenAPI specification on each cut.
Breaking changes ship behind a new API version. Older versions are supported alongside the new one for a published deprecation window so you can migrate on your own schedule.
Production tenants get a named integrations contact and an SLA-backed channel for incidents. Sandbox tenants get response on the next business day, or faster during an active integration.
Responsible disclosure is welcome. Reach out through the contact form to receive the disclosure policy and a coordination channel.
Platform controls — encryption, residency, audit, RBAC, model governance — are documented on the security and compliance page; integrators inherit them automatically.
Tell us what you want to build and we'll set up a sandbox tenant, share the OpenAPI specification, and walk through the first integration with an engineer.