Digital banking APIs

Nucleus lets institutions build or choose customer channels. The existing self-service surface is a subset of the target product; check the server build, enabled modules and customer scope before use.

Authentication

POST /nucleus/api/v1/self/authentication delegates to the existing authentication service. Its base64EncodedAuthenticationKey represents base64(username:password). It is reusable Basic credentials, not a revocable or expiring session token. Do not embed staff credentials in a customer channel. Tenant selection never authorises arbitrary institution access. OAuth, session and step-up behaviour must be verified for the selected deployment.

Existing-customer digital enrolment

POST /nucleus/api/v1/self/registration enrols an existing customer using accountNumber, firstName, lastName, username, password, authenticationMode and email; mobile mode also requires mobileNumber. Source looks up the existing client, validates supplied details, persists registration and sends an authorisation token. Confirmation uses /self/registration/user under its own schema.

This endpoint does not establish new-customer KYC, automatic account opening or a mandatory national identifier. New-customer onboarding is a distinct target journey governed by the institution’s identity and product policies.

Accounts and statements

Discover clients with GET /self/clients, then accounts with GET /self/clients/{clientId}/accounts. Read an account with GET /self/savingsaccounts/{accountId} and a known transaction with GET /self/savingsaccounts/{accountId}/transactions/{transactionId}. Paths here are relative to /nucleus/api/v1.

The snapshot does not establish GET /self/accounts, GET /self/savingsaccounts or a general savings transaction-list endpoint. Statements use a qualified customer report through /self/runreports/{reportName} with approved parameters and scope, or a separately specified channel contract. Never substitute a staff endpoint when a customer endpoint is absent.

Internal and interbank transfers

POST /self/accounttransfers consumes internal source/destination account identities. It does not submit an interbank transfer. The separate /transfers/send implementation currently refuses dispatch while required financial and recovery controls are missing; a licence or flag alone cannot open it.

The target Transfer capability covers domestic, cross-border and stablecoin transfers. Institutions can configure multiple named connections through the optional Transfers add-on or their own integrations. The core owns the instruction, approvals, funding, accounting, durable dispatch and unknown-outcome recovery. Channels submit instructions to the core for funding and dispatch.

Loans and other operations

POST /self/loans submits an application; approval and disbursement are distinct outcomes. Read the versioned schema for the selected operation instead of reusing product assumptions from another institution.

The API overview distinguishes the checked-in snapshot from proposed contracts. Repository references: reference/contracts/CURRENT_API_SURFACE.md, reference/experience/09_DEVELOPER_EXPERIENCE.md and reference/contracts/PROPOSED_EXTENSION_CONTRACTS.md.