What the OCLA Fusion plan asks of Catalyst Platform, how that compares with what is built today, and what we propose to do in each phase.
A proposal for discussion. Nothing here changes the agreed Phase 1 scope. Each change applies only once Catalyst agree it. Figures marked as estimates will be checked against the pilot's real data.
Source: OCLA Fusion Strategy and Operating Plan, presented 15 October 2026. The plan describes a target, and says its capabilities, budgets and rollout still need confirmation.
| Theme | The plan | Catalyst Platform today |
|---|---|---|
| Catalyst Platform's place | One part of Fusion, the shared platform Catalyst builds: the Catalyst Platform workspace, service coordination, a practice workspace and the Datahouse | The Catalyst Platform workspace is built. Service coordination is partly built (service provider library, consent, data packs, manual offers). There is no practice workspace |
| First release | Proven by one real client case from data connection to outcome, including fees and income reconciled | Phase 1 ends when Aurora's response is captured. Income reconciliation is planned for Phase 2 |
| Clients | SMMEs and connected individuals (owners, families, employees) for insurance, investments, benefits and medical cover | No information about individual people is held, on purpose |
| Providers | Funding and credit (including Keypin), financial services, legal, IT and business AI | Any provider can be added as configuration. Today's fields suit service providers such as Aurora |
| Independence | "Group affiliation is not itself a reason to recommend a service" | Matches Catalyst Platform's rule that offers never drive recommendations |
| Manual steps | Acceptable while automation develops, with the same identifiers, statuses and audit record | How the Service provider desk and offer capture already work |
| White labelling | One product under many practice brands | Each practice's colours and logo on the app and its reports; one web address for all practices |
| Management reporting | Comparable reporting and a common scorecard across practices, including practice economics | Not in Phase 1. Practice economics would need the practices' own books |
| Data sources | Xero and SimplePay first | Xero is live in the pilot. SimplePay is built and waits for SimplePay to grant access |
Compared with the agreed Phase 1 plan and the changes already recorded.
| Change | Today | Kind |
|---|---|---|
| Case tracking | Not designed: routing, status, owners, outcomes and follow-up for each service case | New |
| Fees and income reconciliation | Planned for Phase 2 | Moved earlier, if it is part of the first release |
| Practice workspace | Not designed: work queues, relationship owners, capacity, practice-management tools | New |
| Connected individuals | Excluded for privacy | New, and needs a privacy redesign |
| Non-funding providers | The provider model fits; its fields and catalogue grow | Extension |
| Reporting across the network | Not in iteration 1; benchmarks in Phase 3 | New |
| About 400 practices and 200,000 SMMEs | Sized for 1 practice and 50 businesses (Phase 1), about 5 practices and 2,000 businesses (Phase 2) | About 100 times the sizing |
| A web address per practice | One address | Possible |
| Practices' own economics | No data source | New source |
Catalyst and OCLA want reports across the whole network. Each practice's data stays secure and managed by that practice; the network view may be anonymised.
Before any data is used this way: the practice agreement must allow de-identified, combined use of client data for Catalyst's own purposes. The clause should be in the first practice's agreement, because data collected without it is hard to use later. Xero's terms also need checking: they already forbid training AI models on Xero data. Practices outside the OCLA group may have commercial concerns too.
Estimates, to be checked against the pilot's real data.
| Area | At 200,000 businesses | What it needs |
|---|---|---|
| Xero | More connections than Xero's Advanced tier allows (10,000) | Xero's Enterprise tier: certification, a yearly security assessment and an App Store listing |
| Nightly updates from Xero | About 600,000 calls a night with the planned ledger-based sync, roughly an hour within Xero's limit. Today's report-based sync would need about 1–2 million calls | The planned Phase 2 sync changes, and onboarding practices in waves |
| First load of each client | About 60 million calls in total, roughly 100 hours of Xero's full allowance | Onboarding spread over weeks |
| Database | About a billion monthly balance rows, roughly 0.5–1 TB | A larger database in Cape Town, split into partitions, with read copies |
| Stored Xero files | Roughly 1–10 TB | Inexpensive storage with a retention rule |
| Reports | Up to 200,000 a month | A PDF service that scales up and down |
| Network analysis | Billions of rows | The separate analysis copy, never the live system |
Is the technology right? Yes. The Cape Town design (Cloudflare at the edge; the database, files and keys in Cape Town) suits this load, because the heavy work is reading from Xero and storing data, and the design keeps both in South Africa. It needs the planned scaling work brought forward, the separate analysis copy, and moving the rest of prod from the EU to Cape Town before the second practice, which also settles where client data is kept.
Xero limits how many businesses one app may connect to. The limits as published by Xero, last checked August 2026:
| Xero tier | Businesses connected, across the whole app | Needs |
|---|---|---|
| Starter | 5 | — |
| Core | 50 | A payment method |
| Plus | 1,000 | Certification |
| Advanced | 10,000 | Certification and a yearly security assessment |
| Enterprise | No limit | Certification, security assessment and an App Store listing |
Nothing built in Phase 1 stands in the way of these. The analysis copy reads the same tidied data, providers are already configuration, and the scaling work is planned.