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.
Five layers, one API surface, OAuth 2.0 with scoped permissions and signed webhooks, and a sandbox that behaves like production: the developer tour of how CoreFi is put together, before you scroll the API preview below.
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.
Illustrative requests pulled from the OpenAPI 3.1 specification — accounts, payments, KYC, lending decisions, and webhook signature verification. Fields and shapes are representative; the versioned specification shared with sandbox tenants is the source of truth.
POST /v1/accounts
Authorization: Bearer <jwt>
Content-Type: application/json
Idempotency-Key: 8c0d1f4e-a3b5-4e80-9c14-2e1a4f7d18ab
{
"customer_id": "cus_3pZk9mF2v0WqA",
"product": "current_account",
"currency": "EUR",
"owner_type": "person",
"metadata": { "channel": "mobile" }
}
Returns the new account, its ledger reference, and the audit-record id. Requires the accounts.write scope.
POST /v1/payments
Authorization: Bearer <jwt>
Idempotency-Key: 0e1a55b9-7f6d-4b3e-9a02-3c8f5d2e6b71
{
"rail": "sepa_instant",
"from_account": "acc_01HF8M...",
"to": {
"iban": "DE89370400440532013000",
"holder": "ACME GmbH"
},
"amount": { "currency": "EUR", "value": 12500 },
"reference": "INV-2026-04812",
"acting_on_behalf_of": "usr_treasurer_42"
}
Amount is in minor units (cents). The platform evaluates the configured policy gates — transaction limits, sanctions, AML — and may return a pending status awaiting a human approver.
POST /v1/kyc/cases
Authorization: Bearer <jwt>
{
"customer_id": "cus_3pZk9mF2v0WqA",
"case_type": "onboarding",
"risk_inputs": {
"country_of_residence": "IT",
"pep": false,
"expected_monthly_volume": 5000
},
"evidence": [
{ "kind": "id_document", "document_id": "doc_a91..." },
{ "kind": "address_proof", "document_id": "doc_b42..." }
]
}
Cases are routed to the configured reviewer queue. The structured decision rationale is returned on case close and pushed as a kyc.case.decisioned webhook event.
POST /v1/loans/applications/app_01HG9.../decision
Authorization: Bearer <jwt>
{
"outcome": "approved",
"approved_amount": { "currency": "EUR", "value": 2500000 },
"term_months": 36,
"interest_rate_bps": 685,
"rationale": {
"model_id": "credit-v4.2",
"features": { "pd": 0.018, "lgd": 0.30 },
"human_reviewer": "usr_underwriter_7"
}
}
Decisions write to the loan's case file and to the append-only audit record. Required scopes: lending.decisions.write; certain outcomes additionally require dual control configured on the tenant.
// Node example. Reject the request unless the recomputed HMAC
// matches and the timestamp is within the freshness window.
const sig = req.headers['corefi-signature'];
const ts = req.headers['corefi-timestamp'];
const raw = req.rawBody; // Buffer, not parsed JSON
const expected = crypto
.createHmac('sha256', process.env.COREFI_WEBHOOK_SECRET)
.update(`${ts}.`)
.update(raw)
.digest('hex');
if (!crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected))) {
return res.status(401).end();
}
if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) {
return res.status(408).end(); // timestamp outside freshness window
}
Signing keys are rotated through a published key set. The same verification pattern is shipped in the Python, Node, Go and Java SDKs once they are public.
These snippets are illustrative. The versioned OpenAPI 3.1 specification — including pagination, error envelopes, idempotency semantics and full field reference — is shared with sandbox tenants on request.
A reference portal and official SDKs across Python, Node.js, Go and Java are on the roadmap. Until they are public, sandbox tenants get the versioned OpenAPI specification and integration guides delivered through their 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 reference yet.
Pythonic client for backend services, data pipelines and agent runtimes. Generated from the OpenAPI specification. Early access available on request alongside the sandbox.
Typed TypeScript / JavaScript client for Node services and browser integrations. Generated from the same OpenAPI specification so contracts stay in lock-step with the other SDKs.
Idiomatic Go client for high-throughput backends and infrastructure tooling. Same resources, scopes and pagination model as the other SDKs. Early access available on request.
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.
Need a language we have not listed? Tell us in the sandbox request below — SDK language coverage is driven by integrator demand.
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.
Sandbox provisioning is gated today. Share what you want to evaluate, in which language, and we will set up your tenant, share the OpenAPI specification and walk you through the first integration with an engineer.
Sandbox requests route to the integrations queue — not the general sales queue — and a human watches the inbox. We respond on a working-day cadence.
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.
The Developer Center is the surface-level shape of CoreFi: API preview, sandbox tenancy, SDK roadmap and the tool-calling layer for agents. The full integration surface — REST, event streams, webhooks, file-import pipelines, SDKs — and how each mechanism inherits the platform's identity, policy and audit model is documented on the architecture page.
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.