Cortex documentation¶
Cortex is an AI-native banking and back-office platform. One immutable double-entry ledger sits beneath deposits, payments, cards, treasury and lending, and the institution's own books: procurement, sales, inventory, payroll, assets and planning. Every module posts to the same journal, so there is nothing to reconcile between systems.
This site has four parts.
-
Sign in, learn how the console is laid out, and walk one end-to-end flow: open a customer, open an account, post a transfer, read the journal.
-
Operating the admin console, screen by screen: customers and KYC, accounts, payments, cards, teller, the ledger, day-close, approvals and administration.
-
The enterprise side on the same ledger: procure-to-pay, order-to-cash, inventory and costing, assets, projects, planning, period close and consolidation.
-
Authentication, conventions, idempotency, errors, maker-checker and agent access, plus the full API reference: 319 documented operations.
The surfaces¶
| Surface | URL | Who it's for |
|---|---|---|
| Admin console | admin.cortexbanking.com | Bank and back-office staff: operations, approvals, configuration |
| Customer portal | app.cortexbanking.com | Retail customers: accounts, transfers, payments |
| API | api.cortexbanking.com |
Integrations and service clients |
| Identity | auth.cortexbanking.com |
OAuth2 / OIDC token issuance |
How Cortex is put together¶
You never deploy "all of Cortex." A deployment carries only the capabilities it needs, and each signed-in person sees only the modules their role allows. A small business runs the accounting essentials; a bank runs core banking; a bank with its own back office runs both, from one codebase, with each institution's data kept in its own separate database.
Two ideas recur throughout this documentation, so it is worth naming them once:
- Maker-checker (four eyes). Sensitive actions are captured by one person and authorised by another. When you submit one, the console tells you it has gone to Approvals. That is expected, not an error. See Approvals & maker-checker.
- One ledger. Every movement (a card payment, a supplier invoice, a payroll run) ends as a balanced debit and credit in the same journal, categorised in the day book. See Ledger & day book.
Looking for the complete screen-by-screen reference?
The full admin-portal user guide is also available as a single document. See the complete PDF reference. The curated pages here are the recommended starting point.