Cashbook
Client money movements — PayNow Technologies Ltd · CASS 15 compliant ledger
Total Client Money
£4,287,341
Across all client accounts
Today's Movements
£183,420
↑ 12 transactions
Pending Postings
3
Awaiting settlement
Recon Status
⚠ 1 break
EUR leg · under investigation
Journal Entry
Journal Entries
Filter:
| Date / Time | Reference | Client | Event Type | Account | Debit | Credit | Status |
|---|
Chart of Accounts
Configurable account hierarchy for GL translation rules
Account Structure
Point-in-Time Balances
Query account balances as at any historical timestamp — CASS 15 requirement
Total Client Money Balance
£4,287,341.00
As at now (live)
Safeguarding A/c
£4,291,200.00
Shortfall
£0.00 ✓
Active Clients
1,847
Avg Balance
£2,321
Account Balances
| Account | Name | Opening | Movements | Closing |
|---|---|---|---|---|
| 1001 | Client Money Pool | £4,103,921 | +£183,420 | £4,287,341 |
| 1002 | Safeguarding Account | £4,107,780 | +£183,420 | £4,291,200 |
| 2001 | Client Money Liability | £4,103,921 | +£183,420 | £4,287,341 |
| 4001 | Fee Income | £28,440 | +£3,120 | £31,560 |
Point-in-Time Query
Balance as at
GL Translation Rules
Event-triggered double-entry rule configuration — each rule fires on an inbound API event
Active Rules
Event Simulator
Send a test event to see which GL rules fire and what journal entries are created
Inbound Event
Journal Output
Fire an event to see the GL translation output
D+1 Safeguarding Tracker
Receipt-to-payment allocation & firm-account sweep monitoring — CASS 15.8 (relevant funds may be received into a firm account, but must be segregated into a relevant funds bank account by close of business the day after receipt)
1 receipt has breached its D+1 sweep deadline
Receipt PAY-IN-8802 (£22,000 · Yuki Tanaka) was received 31 May and remained in the firm account past COB 01 Jun. Funds must be moved to the relevant funds bank account immediately and a breach recorded.
Received into firm a/c (D)
£28,400
3 receipts · 01 Jun
Allocated / paid out
£12,500
Matched to payee instructions
Still held — to sweep
£37,900
Across firm & in-transit accounts
Overdue sweeps
1
Notifiable breach open
Receipt allocation & sweep status
Reconciliation point: 01 Jun 2026 · COB
| Receipt | Client | Received (D) | Amount | Allocated out | Still held | Sweep by (D+1) | Status |
|---|
Click a receipt to trace how each payment-out was allocated against it. Allocation, not netting, is what determines the D+1 segregation requirement — the engine tracks every receipt from inflow to outflow rather than assuming today's payments came from today's receipts.
D+1 Segregation Check
Requirement (closing)
Relevant funds still held at COB D+1
= received − allocated out − fees£53,400.00
= received − allocated out − fees£53,400.00
Resource (closing)
Relevant funds bank account£31,400.00
Firm account (awaiting sweep)£22,000.00
Relevant assets (value)£0.00
Total resource£53,400.00
Resource vs requirement£0.00
Funds present — but £22,000 sits in the firm account past its D+1 deadline. The amount is safeguarded in substance but non-compliant on form until swept. Flagged, not hidden.
Reconciliations
Internal and external safeguarding reconciliations — performed each reconciliation day, currency by currency. Breaks must be investigated, with cause and remediation recorded (CASS 15.8).
Last internal rec
✓ Balanced
01 Jun · 09:14
Last external rec
⚠ 1 break
EUR leg · under investigation
Open breaks
1
Awaiting remediation record
Recon days completed
21 / 21
May 2026
Internal reconciliation — resource vs requirement
Requirement — sum of individual safeguarding client balances
Funds received£4,512,800
+ Funds paid to client by firm£3,120
− Payments out to payee / payee’s PSP(£198,400)
− E-money redeemed(£26,059)
− Money due from client (fees)(£4,120)
− Individual negative balances (floored)£0
+ Unallocated relevant funds£18,200
Requirement£4,305,541
Resource — cash book records
Relevant funds bank account£4,283,341
Firm account (within D+1)£22,000
Relevant assets (value)£200
Resource£4,305,541
Surplus / (shortfall)£0.00 ✓
External reconciliation — currency by currency
| Currency | Bank / custodian statement | Internal record | Difference | Status |
|---|---|---|---|---|
| GBP | £4,176,210.00 | £4,176,210.00 | £0.00 | Balanced |
| EUR | €151,420.00 | €152,900.00 | (€1,480.00) | Break |
| USD | $88,640.00 | $88,640.00 | $0.00 | Balanced |
Each currency is reconciled separately — an FX trade nets to zero across protected funds but moves both legs, so balances are compared currency by currency, not in a single base-currency total.
Reconciliation breaks
FX Trades
Spot FX execution records — rate and margin captured for validation. An FX trade does not change the total relevant funds protected, but each currency leg must be tracked and reconciled separately.
GBP position
£4,176,210
Relevant funds
EUR position
€152,900
Relevant funds
USD position
$88,640
Relevant funds
FX margin (period)
£1,840
To 4002 · Fee Income
FX trade blotter
| Trade ref | Client | Date | Sell | Buy | Rate | Margin | Status |
|---|
Safeguarding treatment. Where the firm delivers both legs simultaneously, there is no change in relevant funds protected — only the currency composition changes. The captured rate and margin let the engine validate the trade and post the margin to fee income, while each currency leg flows through to the currency-by-currency external reconciliation.
CASS 15 Compliance Report
FCA client money record requirements — auto-generated from Ledger records
Reporting Period
May 2026
Monthly reconciliation
Record Completeness
100%
All transactions captured
Recon Breaks
1
EUR leg · remediation in progress
Audit Readiness
⚠ 1 open
Clears once break remediated
CASS 15 Obligations Checklist
| CASS 15 Requirement | Status | Evidence |
|---|---|---|
| Individual client-level cashbook records | ✓ Met | 1,847 client accounts with full transaction history |
| Point-in-time balance statements | ✓ Met | Temporal query API available for any timestamp |
| Transaction audit trail with dates & status | ✓ Met | Immutable ledger — 14,293 records this period |
| Safeguarding account reconciliation | ✓ Met | Daily recon · 0 breaks identified in May 2026 |
| Client money shortfall identification | ✓ Met | Automated daily check · No shortfalls detected |
| Record integrity & immutability | ✓ Met | Append-only ledger · cryptographic hash chain |
| D+1 receipt-to-payment allocation tracking | ✓ Met | Every receipt traced inflow → outflow; D+1 segregation requirement derived from allocation, not netting |
| Firm-account sweep monitoring (COB D+1) | ⚠ 1 overdue | PAY-IN-8802 (£22,000) breached sweep deadline — flagged for notifiable breach |
| Currency-by-currency external reconciliation | ✓ Met | GBP / EUR / USD reconciled separately against bank & custodian statements |
| Break cause & remediation record-keeping | ⚠ 1 open | EUR break logged; cause and remediation steps required before sign-off |
SUP 16.14A — Monthly Safeguarding Return
ROADMAP PREVIEW
FCA monthly return · Auto-populated from Ledger records · Due within 15 business days of period end
Reporting Period
May 2026
01–31 May 2026
Submission Deadline
21 Jun 2026
15 business days after period end
Auto-Populated Fields
18 / 22
4 require manual attestation
Return Status
⚠ In Progress
Awaiting 4 attestations
4 fields require manual attestation before this return can be submitted to RegData. All financial data has been auto-populated from Ledger records.
Section A — Firm Details
Auto-populated
Firm NameA.1
PayNow Technologies LtdAuto
FRNA.2
900447Auto
Firm TypeA.3
Authorised Payment InstitutionAuto
Reporting PeriodA.4
01 May 2026 – 31 May 2026Auto
Section B — Safeguarding Method
Partial attestation required
Primary safeguarding method usedB.1
⚠ Attest
Safeguarding bank / custodian nameB.2
Barclays Bank PLCAuto
Acknowledgement letter in place?B.3
⚠ Attest
Non-standard safeguarding method in use?B.4
✓
Section C — Relevant Funds & D+1 Reconciliation
Auto-populated from Ledger · CASS 15.8.10R & 15.8.47R
D+1 Segregation Requirement (closing)
Total relevant funds that should be held
C.1
£
From Ledger
D+1 Segregation Resource (closing)
Total funds actually held in safeguarding accounts
C.2
£
From Ledger
Surplus / (Shortfall)C.3
£
✓ No shortfall
Shortfall occurred during period?C.4
NoFrom recon log
Peak relevant funds held (period)C.5
£
From Ledger
Average relevant funds held (period)C.6
£
From Ledger
Section D — Daily Reconciliation Compliance
Auto-populated · CASS 15.8.10R
Reconciliation days in periodD.1
21Auto
Internal reconciliations completedD.2
21 / 21From recon log
External reconciliations completedD.3
21 / 21From recon log
Reconciliation day calendar — May 2026D.4
MoTuWeThFrSaSu
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Reconciled
Non-reconciliation day
Missed
Reconciliation breaks identifiedD.5
0From recon log
Section E — Safeguarding Audit Status
Attestation required · SUP 3A
Statutory auditor appointed?E.1
⚠ Attest
Auditor nameE.2
Safeguarding audit period end dateE.3
Audit report submitted to FCA?E.4
⚠ Attest
Ready to submit to RegData?
Complete the 4 outstanding attestations, then submit via FCA RegData portal. Return due 21 June 2026.
Roadmap preview — RegData submission integration not yet available. Fields marked Auto are populated directly from Ledger records and reconciliation logs.
Audit Trail
Immutable event log — every action timestamped, attributed, and locked
Event Log
Integrations
Connect source systems to Ledger — transactions flow in, GL rules fire, journals are posted
🔗
Webhook / Event Push
Source system posts events to Ledger in real time. Best for modern BaaS and payments platforms.
Connected
14 events received today · Last: 09:14
🔄
Polling API
Ledger calls the source system API on a schedule. Good fallback for systems without webhook support.
Configured
5-min interval · Next poll: 09:19
📂
File Ingestion
Scheduled file drops in CSV, MT940, BAI2 or custom formats. Maximum compatibility with legacy systems.
Available
Not yet configured
Events Today
14
↑ vs yesterday
Success Rate
100%
0 failures
Avg Latency
38ms
Event → journal
Source System
ClearBank
BaaS · REST webhooks
How it works
🏦
Source System
Transaction occurs
→
📡
Ledger Webhook
POST /api/events
→
⚙️
GL Rule Engine
Rule matched
→
📒
Journal Posted
Immutable entry
Map your source system's event types to Ledger GL rules. Unknown events are queued for manual mapping.
| Source Event Type | → | Ledger Rule | GL Trigger | Status |
|---|---|---|---|---|
| payment.credit | → | RULE-PAYMENT_RECEIVED_001 | payment.received | Mapped |
| payment.debit | → | RULE-PAYMENT_SENT_001 | payment.sent | Mapped |
| fee.transaction | → | RULE-FEE_CHARGED_001 | fee.charged | Mapped |
| sweep.outbound | → | RULE-SAFEGUARDING_TRANSFER_001 | safeguarding.transfer | Mapped |
| redemption.complete | → | RULE-REDEMPTION_SETTLED_001 | redemption.settled | Mapped |
| reversal.credit | → | Not mapped | — | Pending |
Last 10 webhook deliveries
Endpoint URL
Configure your source system to POST events to this endpoint:
https://ledger.paynow.co.uk/api/v1/events
Authentication
Include your API key in the request header:
X-Ledger-Key: lk_live_••••••••••••••••
Expected Payload
{
"event_type": "payment.credit",
"event_id": "evt_8841_abc",
"timestamp": "2026-06-01T09:14:00Z",
"amount": 5000.00,
"currency": "GBP",
"client_ref": "CLI-00847",
"source_ref": "PAY-IN-8841"
}
"event_type": "payment.credit",
"event_id": "evt_8841_abc",
"timestamp": "2026-06-01T09:14:00Z",
"amount": 5000.00,
"currency": "GBP",
"client_ref": "CLI-00847",
"source_ref": "PAY-IN-8841"
}
Ledger returns HTTP 200 + journal entry ID on success. Failed deliveries are retried up to 3× with exponential backoff.
Poll Interval
5 min
Configurable
Last Poll
09:14
3 transactions
Source API
Mambu
Core banking · REST
Status
⚠ Configured
Auth pending
Auth token expires in 3 days. Refresh the OAuth token in Setup to prevent polling interruption.
How polling works
Ledger calls your source system's transaction API every 5 minutes, retrieving records created since the last checkpoint timestamp. Each transaction is matched against the field mapping configuration and dispatched to the GL rule engine. Idempotency keys prevent double-posting if the same transaction appears in multiple polls.
Map fields from the source API response to Ledger's event schema.
| Ledger Field | ← | Source API Field | Transform |
|---|---|---|---|
| event_type | ← | transactionType | lookup(typeMap) |
| amount | ← | amount.value | decimal(2) |
| currency | ← | amount.currency | passthrough |
| client_ref | ← | linkedAccount.id | passthrough |
| timestamp | ← | creationDate | ISO8601 |
| source_ref | ← | encodedKey | passthrough |
API Configuration
Checkpoint & Recovery
Ledger stores a checkpoint timestamp after each successful poll. If polling is interrupted, it resumes from the last checkpoint — no transactions are missed or double-posted.
Last checkpoint2026-06-01T09:14:00Z
Transactions since3
Idempotency key fieldencodedKey
File ingestion is the lowest-barrier integration path
Suitable for firms whose core banking or policy admin system can export transaction files on a schedule — even if it has no API. Ledger picks up files from a secure SFTP location, parses them, maps fields to the event schema, and dispatches to the GL rule engine. No inbound firewall rules required on your side.
📁
Drop a file
Source system exports CSV, MT940 or BAI2 to an SFTP folder on a schedule
🔍
Ledger parses it
Fields mapped to event schema, duplicates detected via reference matching
📒
Journals posted
GL rules fire per transaction, immutable entries created in the ledger
| Format | Description | Typical Source | Status |
|---|---|---|---|
| CSV | Configurable column mapping, any delimiter | Most systems, Excel exports | Supported |
| MT940 | SWIFT bank statement format | Traditional banks, custodians | Supported |
| BAI2 | Bank Administration Institute cash management | US banking, some UK clearing banks | Supported |
| ISO 20022 | camt.053 bank-to-customer statement | Modern banking, new payment rails | Roadmap |
| Custom XML/JSON | Configurable schema mapping | Bespoke policy admin systems | Supported |
SFTP Configuration
Your SFTP Credentials
Alternatively, grant Ledger read access to your SFTP. Use these credentials in your source system's export configuration:
Host: sftp.ledger.bravura.com
Port: 22
User: paynow-ingest
Auth: SSH key (download below)
Port: 22
User: paynow-ingest
Auth: SSH key (download below)
Product Brief — Bravura Ledger
Initiative brief · Confidential · June 2026
Key Highlights
Discovery
CASS 15
Problem Statement
Product Concept
Opportunity
Bravura Modular
Integration
SWOT
Recommendation
Discovery Questions
Bravura Solutions · Product Strategy
Bravura Ledger
A Standalone GL & Cashbook Engine for Regulated Financial Institutions
Initiative Type
New Product
Priority
Discovery
Regulatory Driver
CASS 15
Target Market
PI / EMI
Executive Summary
Payment institutions (PIs) and e-money institutions (EMIs) operating under CASS 15 face a critical gap: they lack purpose-built software to maintain compliant client money cashbook records, point-in-time balances, and full transaction audit trails. Most are managing these obligations in spreadsheets.
Bravura already possesses the core IP to solve this problem. Sonata's GL translation engine — a configurable, event-driven rules system that creates double-entry journal entries on state transitions — maps directly onto the CASS cashbook requirement. The opportunity is to decouple this capability from Sonata's monolithic architecture and offer it as a standalone, API-first product.
This brief proposes a discovery phase to validate market demand, size the opportunity, and determine the build vs. configure investment required. The initiative is positioned as an addition to the existing Bravura Modular proposition, which already encompasses FinoComp microservices, Employer Connect, and a range of Sonata-derived microservices.
Key Highlights
Market Driver
CASS 15 extends client money rules to PIs/EMIs, creating an immediate and largely unmet compliance need for cashbook record-keeping.
Core IP Exists
Sonata's GL translation engine already delivers configurable double-entry journalling on event triggers — the foundational capability needed.
Modular Strategy
Bravura Ledger would extend the existing Bravura Modular proposition — which already includes FinoComp microservices, Employer Connect, and Sonata-derived services — into the PI/EMI compliance market.
Land & Expand
A PI/EMI buying Ledger for compliance today may grow into a broader platform need — creating a pipeline pathway to Sonata or further Bravura modules.
Discovery Findings — Clare O'Driscoll, CASS Consultant
Meeting: 2 June 2026
Clare O'Driscoll is a CASS 15 compliance consultant working with multiple payment institutions and EMIs. She initiated contact having identified a consistent gap across her client base — a lack of any purpose-built record-keeping system for CASS 15 obligations. Key findings from the discovery conversation:
Market Reality
Firms are using niche trading systems that capture FX trades but not client balances, supplemented with Excel. The workload of manual daily cashbook records is unsustainable and audit exposure is material.
Competitive Landscape
"Every time I look for a platform, all I find is reconciliation tools." AutoRec specifically offers only the rec piece — not record-keeping. No purpose-built CASS 15 record-keeping platform exists.
The D+1 Problem
Tracking each receipt's outflows to determine D+1 compliance — which specific payment drew from which receipt — is the hardest operational problem. Impossible in Excel, unaddressed by existing tools.
PSI vs EMI Distinction
PSIs forward money to third parties — no client-facing balance needed. EMIs hold balances visible to clients. Ledger V1 targets the PSI back-office need; an EMI client portal is a later extension.
FX & Multi-Currency
Spot FX trades are common. The trade doesn't change total relevant funds protected, but each currency leg must be tracked and reconciled separately. Rate and margin must be captured for validation.
Dual Account Scope
Unlike CASS 7, CASS 15 permits funds into a firm account (not just RFBA directly), provided they move by D+1. Both firm account and RFBA must be included in reconciliations — a specific design requirement.
"Is there a Sonata for payment services? The answer is no, not at the moment." — Clare O'Driscoll, 2 June 2026. Clare confirmed she will explore introducing Bravura to a client currently in breach since 7 May 2026 who needs a solution urgently. This is a concrete design partner opportunity.
Partnership Opportunities Identified
Clare / Consulting firm
CASS 15 domain expertise and design partner introduction. A formal revenue-share arrangement faces billable utilisation constraints, but Clare expressed genuine interest in being involved in the build.
AutoRec
Already has CASS 15 clients for reconciliation but not record-keeping. A partnership could offer a complete solution — Ledger for records, AutoRec for recs — with referral flow in both directions.
CASS 15 — Regulatory Background & Requirements
FCA PS25/12 · In force 7 May 2026
Origin & Context
CASS — the Client Assets Sourcebook — is the FCA's framework governing how firms hold and protect client money and assets. Until recently, its stricter provisions (notably CASS 7) applied primarily to investment firms. Payment institutions and e-money institutions operated under lighter safeguarding obligations in the Electronic Money Regulations 2011 (EMRs) and Payment Services Regulations 2017 (PSRs) — obligations that, in practice, many firms struggled to meet consistently.
The inadequacy of these lighter-touch rules was exposed by a series of firm failures. The collapse of Ipagoo in 2019 revealed an average shortfall of 65% in funds owed to clients — a stark illustration of the systemic risk. Following HM Treasury's Payment Services Regulations Review (January 2023) and the FCA's subsequent consultation paper CP24/20 (September 2024), the FCA published Policy Statement PS25/12 in August 2025, introducing CASS 15 as a materially strengthened safeguarding regime for PIs and EMIs.
Implementation Timeline
Stage 1 — Supplementary Regime
In force: 7 May 2026
The Supplementary Regime (CASS 15, CASS 10A, SUP 3A, SUP 16.14A) overlays and strengthens the existing EMR/PSR safeguarding provisions. It introduces specific, operational obligations around reconciliation, books and records, resolution packs, external audit, and monthly FCA reporting. Firms had a 9-month transition window from August 2025.
Now in effectStage 2 — Post-Repeal Regime
Date: TBD — on hold
The more sweeping end-state reform — which would replace EMR/PSR safeguarding entirely with a full CASS-style statutory trust regime — has been paused following consultation feedback and government concern about regulatory burden. The FCA will review the Supplementary Regime after one full audit cycle before consulting again. Firms should plan for further tightening in due course.
Paused — watch briefFirms in Scope
Authorised Payment Institutions
(excl. PIS/AIS-only)
(excl. PIS/AIS-only)
Authorised E-Money Institutions
Small E-Money Institutions
Credit Unions issuing e-money in the UK
Small payment institutions may opt in voluntarily. Banks providing business banking to affected firms should also consider the indirect impact.
The Five Core Obligations
1. Books & Records
CASS 15 core
Firms must maintain accurate, up-to-date books and records of all relevant funds held, including client-level transaction history and balances. Records must be sufficient for the FCA to identify the position of each client at any given point in time.
Gap for most firms: client-level ledger does not exist; position reconstructed manually from bank statements.2. Daily Reconciliation
Every reconciliation day
Safeguarded funds must be reconciled on every reconciliation day (business days excluding weekends, UK bank holidays, and days when relevant foreign markets are closed). The reconciliation must compare the D+1 segregation requirement against the funds actually held in safeguarding accounts. Any shortfall must be remedied immediately and the process documented.
Gap: most firms run weekly or monthly reconciliations manually in spreadsheets; daily cadence is operationally unachievable without automation.3. Monthly FCA Returns
SUP 16.14A
Firms must submit monthly regulatory returns to the FCA (SUP 16.14A) providing detailed information about their safeguarding arrangements, reconciliation outcomes, and the total value of relevant funds held. This gives the regulator ongoing visibility and allows early identification of emerging problems.
Gap: no structured data source from which to produce the return; currently an entirely manual exercise.4. Annual Safeguarding Audit
SUP 3A · mandatory
Firms that have safeguarded £100,000 or more during the year must engage a qualified, regulated auditor. The audit will focus on the accuracy of books and records of safeguarded funds and the effectiveness of internal safeguarding systems and controls. The FRC is developing a new auditing standard specifically for CASS 15.
Gap: firms cannot pass an audit of records they do not maintain; the audit obligation creates an acute forcing function.5. Resolution Pack
CASS 10A · 48hr retrieval
Firms must maintain a resolution pack detailing: locations of safeguarded funds, lists of agents and distributors, flow of funds, and procedures for managing client assets in the event of failure. The pack must be retrievable within 48 hours of FCA request. It is a living document, not a one-off exercise.
Gap: without a structured ledger, the flow-of-funds narrative cannot be produced reliably or quickly enough.How Bravura Ledger Addresses Each Obligation
| CASS 15 Obligation | Bravura Ledger Capability | Coverage |
|---|---|---|
| Books & records — client-level transaction history | Immutable double-entry ledger with client-level journal entries on every event | Full |
| Point-in-time balances for reconciliation | Temporal balance query API — balance as at any timestamp, any account, any client | Full |
| Daily reconciliation — D+1 segregation check | Automated daily recon comparing ledger position vs safeguarding account balance; shortfall flagging | Full |
| Monthly FCA return (SUP 16.14A) | Structured ledger data auto-populates 18 of 22 return fields; 4 manual attestations required | Preview |
| Annual safeguarding audit evidence | Cryptographic hash chain on all records; full audit trail exportable for auditor review | Full |
| Resolution pack — flow of funds, 48hr retrieval | Complete transaction history and balance snapshots immediately retrievable via API or export | Full |
The audit obligation is the forcing function. Most firms can defer books-and-records improvements indefinitely — until their first mandatory annual audit. A firm that has safeguarded over £100,000 (which is almost all PIs and EMIs) cannot pass an audit of records it does not maintain. The audit creates a hard deadline that no amount of goodwill or manual workaround can bridge.
Problem Statement — The Technology Gap
Despite CASS 15 now being in force, the majority of affected firms do not have purpose-built software to meet their obligations. Their core systems were built for operational purposes — processing payments, issuing e-money, managing accounts — not for maintaining a compliant financial ledger. The gap between what the FCA requires and what most firms can currently produce is substantial.
The Excel cashbook. Client money movements tracked manually in spreadsheets — no audit trail, no point-in-time query, no daily reconciliation automation.
Fragmented systems. Client balances in one system, payment records in another, safeguarding account statements in a third — no single source of truth.
No temporal records. Systems show current state only — reconstructing a balance as at a prior date requires a manual exercise that may take days.
Audit unreadiness. The annual safeguarding audit requires evidence of accurate records and effective controls — neither of which manual processes can reliably demonstrate.
There are over 300 FCA-authorised payment institutions and e-money institutions in the UK. For most of them, CASS 15 is not a future planning item — it is a current compliance obligation with an audit deadline approaching. This is the market Bravura Ledger is designed to serve.
Product Concept
"The compliance record-keeping layer that sits behind any core banking or payments system — configured for your COA, your rules, your regulatory obligations."
Bravura Ledger is a standalone, API-first GL and cashbook engine purpose-built for regulated financial institutions. It receives events from external systems, applies configurable translation rules, and produces immutable double-entry journal records against a configurable chart of accounts.
Core Capabilities
⬡
Rules Engine
Event-driven GL translation — configurable triggers mapped to any inbound event type
⬡
Double-Entry Integrity
Debit/credit symmetry enforced at the engine level on every posting
⬡
Temporal Balances
Point-in-time balance queries via API — balance as at any historical timestamp
⬡
Immutable Audit Trail
Append-only ledger — every entry timestamped, attributed, and locked
⬡
Configurable COA
User-configurable chart of accounts with account hierarchy, type classification, and currency support
⬡
API-First Architecture
RESTful API surface for inbound events and outbound balance/report queries
Bravura IP Foundations — What Needs Building
| Sonata Capability | Ledger Equivalent | Work Required |
|---|---|---|
| GL Translation Rules | Event-to-journal mapping engine | Decouple from Sonata registry data model |
| Chart of Accounts config | Configurable COA with hierarchy | Expose via admin UI, not XML config |
| Double-entry journal creation | Immutable ledger entries | Add append-only enforcement + timestamps |
| State transition triggers | Inbound event API | Replace internal events with REST webhooks |
| Financial transaction records | Point-in-time balance API | Add temporal query layer |
Opportunity Assessment
| Dimension | Assessment | Rating |
|---|
Strategic Context — Bravura Modular
Bravura Ledger is best understood not as a one-off product, but as an addition to the existing Bravura Modular proposition. Bravura Modular already encompasses FinoComp microservices, Employer Connect, and a range of Sonata-derived microservices. Ledger would extend that proposition into a new adjacent market — regulated payment institutions and e-money firms — applying the same modular philosophy to a compliance-driven use case.
| Module | Sonata Source Capability | Target Market |
|---|---|---|
| Bravura Ledger ← this initiative | GL translation + COA engine | Payment institutions, EMIs, neo-banks — CASS 15 |
| Bravura Compose | Document generation & correspondence | Any regulated firm requiring templated client comms |
| Bravura Orchestrator | Workflow & process orchestration | Ops teams requiring configurable workflow |
| Bravura Pricing | Unit pricing & valuation engine | Asset managers, boutique investment platforms |
Bravura Modular already includes FinoComp microservices, Employer Connect, and Sonata-derived microservices. Ledger, Orchestrator, and Pricing are indicative additions pending separate assessment.
Integration Patterns
Ledger must receive transaction events from the firm's existing core banking or policy admin system. Three integration patterns are supported, accommodating everything from modern BaaS platforms to legacy systems with no API capability.
🔗 Webhook / Event Push
Preferred · real-time
Source system POSTs a JSON event to Ledger's inbound API on each transaction. GL rule fires immediately. Best for modern BaaS platforms (ClearBank, Griffin, Modulr) that emit webhooks natively.
🔄 Polling API
Pragmatic · near real-time
Ledger calls the source system's REST API on a configurable schedule (1–60 min), pulling transactions since the last checkpoint. Good for platforms with queryable APIs but no webhook support (Mambu, Thought Machine, 10x).
📂 File Ingestion
Maximum compatibility · scheduled
Scheduled file drops via SFTP in CSV, MT940, BAI2 or custom formats. Meets firms where they are today — no API required on the source side. Critical for legacy policy admin and bespoke core banking systems.
Key engineering consideration: GL translation rules in Sonata are written against Sonata's internal event vocabulary. Ledger requires a configurable event schema layer — allowing firms to map their source system's transaction type names to Ledger's GL rule triggers. This event mapping configuration UI is a distinct piece of product work and should be scoped in the engineering assessment.
Discovery questions — integration
What core banking or policy admin system does the firm run? Does it have a REST API or webhook capability?
Can the system export transaction files (CSV, MT940) on a schedule today — even if only manually?
Who owns the source system relationship — is there an internal IT team or is it managed by a third party?
What latency is acceptable for record-keeping — real-time, hourly, or end-of-day is sufficient for CASS purposes?
Integration Patterns
Ledger must receive transaction events from the firm's existing core banking or policy admin system. Three integration patterns are supported, accommodating everything from modern BaaS platforms to legacy systems with no API capability.
Webhook / Event Push
Preferred - real-time
Source system POSTs a JSON event to Ledger's inbound API on each transaction. GL rule fires immediately. Best for modern BaaS platforms (ClearBank, Griffin, Modulr) that emit webhooks natively.
Polling API
Pragmatic - near real-time
Ledger calls the source system's REST API on a configurable schedule, pulling transactions since the last checkpoint. Good for platforms with queryable APIs but no webhook support (Mambu, Thought Machine, 10x).
File Ingestion
Maximum compatibility - scheduled
Scheduled file drops via SFTP in CSV, MT940, BAI2 or custom formats. No API required on the source side. Critical for legacy policy admin and bespoke core banking systems.
Key engineering consideration: GL translation rules in Sonata are written against Sonata's internal event vocabulary. Ledger requires a configurable event schema layer allowing firms to map their source system's transaction type names to Ledger's GL rule triggers. This event mapping configuration UI is a distinct piece of product work and should be scoped in the engineering assessment.
Discovery questions
What core banking or policy admin system does the firm run? Does it have a REST API or webhook capability?
Can the system export transaction files (CSV, MT940) on a schedule today?
Who owns the source system relationship - internal IT or a third-party managed service?
What latency is acceptable - real-time, hourly, or end-of-day sufficient for CASS purposes?
SWOT Analysis
Strengths
- → Proven GL translation engine IP in production at scale
- → Configurable COA and rule framework — no hardcoded logic
- → No equivalent purpose-built competitor product identified
- → Strong Bravura brand in UK regulated financial services
Weaknesses
- → No current market presence in PI/EMI segment
- → Decoupling from Sonata monolith is non-trivial engineering
- → New sales motion and pricing model required from scratch
- → Small engineering team — capacity constraints are real
Opportunities
- → CASS 15 creates immediate regulatory urgency
- → 300+ target firms in UK, largely underserved by vendors
- → Land-and-expand pathway from Ledger to broader modules
- → Design partner programme could fund initial development
Threats
- → Generic GL vendors may add CASS templates
- → FCA regulatory change could narrow the obligation
- → Larger RegTech players (Gresham, Vermeg) could enter
- → Risk of building without sufficient market validation
Proposed Next Steps
| # | Action | Owner / Timing |
|---|---|---|
| 1 | Conduct structured discovery call with Clare to validate problem size, firm profiles, and willingness to pay | Done ✓ |
| 2 | Secure design partner introduction via Clare O'Driscoll — 1 client confirmed in breach since 7 May, awaiting consent to connect. Separately, approach AutoRec re: combined records + reconciliation partnership. | Nick — 2 weeks |
| 3 | Engineering assessment: effort to decouple GL translation engine from Sonata and expose via REST API | CTO — 4 weeks |
| 4 | Produce commercial model: pricing approach, ACV range, implementation model (SaaS vs managed) | Product + Finance — 6 weeks |
| 5 | Board / CPO decision: invest in MVP build, or partner with a third-party GL vendor | CPO — 8 weeks |
Recommendation
Proceed to design partner engagement. Market discovery has validated the opportunity — no competing record-keeping platform exists, CASS 15 is live and firms are in breach, and an introduction to a first design partner client is available via Clare O'Driscoll. Priorities: secure one paid design partner engagement, begin engineering scoping of the GL engine decoupling, and explore an AutoRec partnership for a combined records and reconciliation proposition. Assign a CPO sponsor and add formally to the Bravura Modular product strategy.
Discovery Questions for Market Conversations
Problem Validation
- Walk me through how your firm currently maintains client money cashbook records — what systems, what manual steps?
- What does your CASS 15 compliance process look like today? Where are the gaps you're most concerned about?
- Have you had any FCA conversations or audit findings relating to your record-keeping?
- Is "balance as at a specific date" something you can produce today, or a manual reconstruction exercise?
Current State & Pain
- Which systems hold your client-level transaction data? Are they the same systems used for safeguarding?
- How many people are involved in maintaining CASS records, and how much time does it take?
- What happens at month-end or when the FCA asks for a snapshot? Where does the process break?
- Have you looked at any software vendors to solve this? What did you find and why didn't it work?
Market & Sizing
- How many firms in your network are dealing with the same problem? Are they similar in size and complexity?
- Is CASS 15 the only driver, or is there a broader operational need — reconciliation, reporting, investor money tracking?
- What's the range of firm sizes — transaction volumes, client money AUM, headcount?
Commercial & Procurement
- How do your clients typically buy software — direct licence, SaaS, managed service? What's the procurement process?
- Is there a budget attached, or is this still in the "we know we need to do something" phase?
- Would any clients be interested in a design partner arrangement — early access in exchange for co-design input?
- What would a minimum viable solution look like — what must it do in V1 for a firm to commit?