Platform Architecture

The diagram below shows the platform organised into six layers: client access, secure edge, application, core data, background processing, and observability.

For buyers and evaluators: every capability shown is included and pre-wired. Deployment is a single operation, not an integration project. You are not assembling a platform from parts — you are switching one on.

How the platform is reached:

Every request passes a hardened global edge — DDoS protection, web application firewall, CDN, automatic HTTPS and rate limiting — before it reaches the platform at all.

For system integrators: all business logic is reached through one authenticated REST API. Authentication is JWT or OIDC. High-frequency transaction traffic is served on a dedicated throughput channel, so batch and reporting workloads can never starve payment processing. The complete OpenAPI specification is published and browsable at swagger.ledgerflow.ai.

The amber secure edge band at the top shows the public-facing domains — threat protection, firewall, content delivery and TLS all resolved before a request enters the platform.

The orange governed API surface band is the single door to business data. There is no side entrance: every request is authenticated, permission-checked and audited before it reaches a single record — and the same rules apply whether the caller is the web console, the customer app, a partner integration or an AI agent.

Third-party integrations (left) are deliberately held at arm's length. They are reached asynchronously, so an outage or a slow response at a payment switch, gateway or partner can never stall the ledger itself.

Every financial movement is recorded as a balanced set of postings across debit and credit accounts, with GAAP-compatible double-entry rules enforced automatically. Clients submit amounts and accounts; the engine handles the accounting.

Debit and credit signs are normalised by account type, so a whole class of costly sign-entry errors simply cannot occur. Transactions support reversals, dual-currency settlement with automatic foreign exchange, configurable fee and commission generation, and deep hierarchical account structures where balances roll up to parents in real time.

Batches of staged transactions move through a controlled approval lifecycle: Pending → Pre-Authorised → Authorised → Processed, or Rejected.

The critical part is where that rule lives. Separation of duties is enforced inside the platform core, not in application code — so the same person cannot both raise and approve a batch, and no client, integration or misconfigured front-end can talk its way around it. That satisfies regulatory separation-of-duties requirements without bolting on extra middleware, and every state change is recorded with the user, the timestamp and the full before-and-after state.

LedgerFlow's fraud engine learns each account's own rhythm — the hours, days and dates it normally transacts — and flags departures from it.

Because the model understands that time is a cycle rather than a straight line, activity late at night and in the early hours is correctly recognised as one continuous pattern, not two unrelated extremes. That is the difference between catching genuine overnight anomalies and drowning your analysts in false positives.

Baselines are built per account over a rolling 90-day window across three independent time dimensions, and scoring happens the moment a transaction posts — no overnight batch, no waiting until morning to discover last night's fraud.

Import partner statement files and match them against your ledger using configurable templates — field mappings, date formats, tolerance thresholds and multi-account scope, all without code.

Each run produces three answers your finance team actually needs: matched pairs, unmatched partner rows (their exceptions) and unmatched ledger rows (money you expected and did not receive). Multiple currencies are supported per run, and every import, match decision and exception is persisted for audit.

LedgerFlow pushes events to connected browsers, mobile apps and integrated systems the instant they happen — no client-side polling, no refresh button.

Messages can broadcast to every connected user or target one individual. The same credential that authenticates the REST API grants the event stream, so there is no second set of keys to issue, rotate or leak.

Typical events: transaction confirmed, batch approved or rejected, KYC status changed, balance threshold reached, system alert.

Individuals, merchants and vendors are managed with full KYC status tracking — pending → verified → rejected → expired. Uploaded documents are read and classified automatically, then stored with integrity hashing so tampering is detectable.

The customer portal covers statements, push payments, payment requests, fund loading and settlement through third-party switches and gateways, and live transaction notifications — all governed by the same access-control model as the back office, so customer-facing convenience never becomes a security exception.

One REST API covers the whole platform — transactions, accounts, approvals, reconciliation, customers, KYC and payments. It is standards-based JSON over HTTPS, described by a published OpenAPI specification, so it works with the tooling and language you already use. There is no proprietary SDK to adopt and no client library to keep in step with our release cycle.

Base URL: https://api.ledgerflow.ai

Getting authenticated: exchange credentials for a bearer token and present it on subsequent requests, or federate through OIDC single sign-on against your existing identity provider.

Throughput routing is automatic. Payment and approval traffic is directed to a dedicated high-throughput channel with no special configuration in your client — you integrate once, and the platform handles the load characteristics.

Browse the full specification at https://swagger.ledgerflow.ai — every endpoint, request schema and filter, explorable in the browser without writing a line of code.

Core money movement — post transactions with an idempotency key so a retried request can never double-charge; issue reversals; settle across two currencies in a single call with foreign exchange applied automatically.

Approvals — raise a batch, stage transactions into it, and submit it for authorisation, with separation of duties enforced by the platform rather than your integration code.

Customer payments — send funds, request funds, and let a payer approve and settle a request.

The heavy lifting stays server-side. Sign normalisation, fee and commission rules, balance roll-up and audit logging all happen inside the platform, so your integration supplies accounts and amounts and nothing more.

Access is controlled by a seven-layer security model, and a request must clear every one:

1. Secure edge — threat protection, firewall and TLS termination before the platform
2. Gateway — rate limiting and request routing
3. Session or token validation
4. Account status and credential-expiry checks
5. Fine-grained permissions — 25+ categories, read / read-write / read-write-delete
6. Role assignment — every operation executes under the user's own authority
7. Record-level security — data filtered at the core, beneath the application

The last two matter most. Authorisation is enforced at the deepest layer of the platform rather than in front-end code, so a flaw in an application, an integration or a query cannot expose data the user was never entitled to see.

Single sign-on federates with Keycloak, Auth0, Microsoft Entra or any standards-compliant OIDC provider, with federated identities mapped to internal roles on first login. Multi-factor authentication and passkeys are supported.

Every create, update and delete across the platform is captured automatically, recording:

• Timestamp of the change
• User responsible
• Client IP address
• Action type — create / update / delete / download
• Before state — the full previous record
• Changed fields — precisely what differed

Capture is automatic and unconditional. It is not something a developer has to remember to call, so it cannot be forgotten in a new feature or quietly omitted under deadline pressure.

Audit records live in a dedicated restricted area that application code cannot write to, alter or delete — including administrators. They are fully indexed for fast investigation by user, time, record, action or IP address.

Single-node / evaluation — the entire platform starts with one command. No external dependencies to procure, install or configure first. Every component comes up together, already wired, in minutes rather than a multi-week integration.

Production scale-out:

• High availability through replication of the core data layer
• Load balancing across application nodes
• Integration with your existing secrets management
• Horizontal scale — API and background processing are stateless, so you add capacity by adding replicas
• Object storage for backup, high-performance storage for active data

Indicative single-node sizing: core data layer 8 CPU / 16 GB RAM / 500 GB SSD · application 4 CPU / 8 GB · observability 2 CPU / 4 GB

Each customer deployment is fully ring-fenced — your own dedicated stack, sharing nothing with anyone else's data or workload.