Future-State Technology Strategy and Operating Model

1Executive summary

Deliverable 1 established the current state and the gaps. It found a Group that has scaled faster than its systems have integrated, with a capable but dated core, no automated integration between platforms, and data captured and moved by hand. It named one root cause beneath the three success criteria, accuracy, governance and scalability, and it was not the absence of a capable system. It was how data gets in and how it moves.

This deliverable sets the design that answers that. The design principle is simple and it follows directly from that finding: the answer to a data problem is to own the data, not to buy another application to hold it. The Group's single source of truth becomes a data layer the Group controls, the golden record and the single client and entity identifier, fed by an automated ingestion layer that fixes capture at the point of entry, with the applications around it kept as specialist, swappable tools. It is a data-centric architecture: systems and data first, with AI as the layer that gets data in and drafts documents on top.

• Own the record. The source of truth is a data layer the Group owns, not a platform a vendor delivers. This is the golden record the gap report said the Group lacked, put where it belongs.
• Automate the input. An ingestion layer, automated intake, extraction and validation, closes the capture problem the gap report identified as the root cause. This is the part no platform migration was ever going to solve on its own.
• Keep the applications swappable. Finance, screening, audit and statutory filing sit around the record as specialists, connected by a governed integration layer. None is load-bearing, and any can be replaced without touching the record.
• AI is the layer, not the strategy. Claude and Co-pilot do the extraction at the input boundary and the document drafting on top, governed and human-reviewed, not the architecture itself.

The headline recommendation. Build and operate an owned data core and ingestion layer, keep the specialist applications as swappable spokes chosen on integration and replaceability, and use AI at the input boundary and for drafting. This removes the single-vendor dependency that the platform route carried, puts the golden record under the Group's control, and lets the quick wins land without waiting on any one system to go live. The onboarding workstream, the top of the gap report's value-against-risk matrix, is the first proof of the design, not a special case.

2How to read this report

2.1 What this deliverable covers

This is the second of the three Stage 1 deliverables set out in the proposal. It covers the future state: the target technology architecture, the to-be workflows for the priority workstreams, the data and automation strategy, the AI tools integration plan including Co-pilot and Claude, the capability evolution framework, and the operating model for steady state. It does not size the work or sequence the build, that is the transformation roadmap in Deliverable 3.

2.2 The system-of-record direction

The Group entered this engagement leaning toward migrating to Quantios as the system of record, and the earlier drafts of this design were built around it. Discovery and vendor due diligence changed the recommendation, and this deliverable reflects the changed view rather than the starting assumption. The full reasoning is in Section 7. In short, a platform migration would place the Group's operating reality inside a single vendor's delivery timeline against a hard Q4 2026 deadline, it would not by itself solve the capture problem that is the Group's largest source of manual work, and the one capability that most justified the platform, regulatory reporting, turned out to be jurisdiction-gated on precisely the two regimes the Group most needs. The design here keeps what a platform did well and removes the dependency the Group cannot control.

2.3 The closure-path ordering, carried forward

The gap report classified every gap by how it could be closed, in order from the lowest cost and risk to the highest: configure what exists, integrate what exists, remediate the data, and only then build. That ordering still governs. The difference in this design is that the one thing worth building, the owned data core and its ingestion layer, is the thing the first three paths cannot substitute for, because it is the Group's data, not an application.

3Target technology architecture

The current-state map in the gap report showed every system connected through a manual Excel hub. The target state replaces that hub with data the Group owns. The record sits at the centre, data enters it through a single ingestion layer that fixes capture, and the specialist applications sit around it as swappable spokes. What changes is not mainly which tools are used, most are the ones the Group already runs, but where the source of truth lives.

3.1 The owned data core, the source of truth

A data layer the Group owns holds the golden record: one client, one entity, one filing, each existing once, under a single enforced identifier. This is the thing the gap report said the Group lacked, and it is the thing a platform migration would have placed inside a vendor's product. Owning it directly is what makes every other decision reversible: tools around it can change, but the record does not move. It is also what most directly serves the intercompany servicing model, where M/HQ onboards and Rethink or RAA service the same client, the model that multiplies duplication today.

3.2 The ingestion layer, how data gets in

This is the part of the design that answers the gap report's root cause. Automated intake, extraction and validation sit at the boundary, so that a document, a form or a portal submission is turned into structured, validated data before it reaches the record, rather than being keyed by hand and re-keyed across systems. It is the layer that stops the Group defaulting to Excel, because for the first time capture is a system function rather than a manual one. Fixing input is the highest-leverage move in the whole architecture, and it is deliberately independent of any one downstream system going live.

3.3 The specialist spokes, swappable, none load-bearing

Around the record sit the applications that do specialist work: Xero for accounting, KYC360 for screening and client intake, Inflo for audit execution, a statutory-filing capability, and corporate-secretarial workflow. Each connects to the record through a governed integration and each is chosen on two tests: does it expose a proper API, and can it be replaced without disturbing the record. Because the source of truth is owned, no spoke is load-bearing. The finance spoke is the clearest illustration of why this matters. The Group tested the new AI-enabled version of Xero and found the output quality wanting, so rather than depend on it, the design feeds Xero clean, prepared data from the ingestion layer. That reduces dependency on Xero's own AI to the point where it can be turned down to zero, or Xero itself swapped out, without touching the record.

3.4 Regulatory reporting without a platform dependency

Regulatory reporting was the strongest argument for a trust-and-corporate-services platform, so the design keeps the capability and removes the dependency. Two things carry it. Statutory filings for ADGM and DIFC, the annual returns and change filings the Group makes most often, are generated as templated documents off the owned entity data, which is a bounded, well-understood set of forms. AEOI (FATCA and CRS) runs on a single OECD schema that is the same across jurisdictions and is handled by a dedicated component, either a commodity provider or built to the schema. Neither depends on a platform holding the record.

3.5 The AI layer

Across the top sits the AI layer: Claude and Co-pilot, doing the extraction at the ingestion boundary and the document drafting on top of the record. It is drawn as a layer touching the architecture rather than a box inside it, because its role is to assist capture and drafting, not to be the system of record. Section 6 sets out the plan, and the framing throughout is the one the ops team asked for: systems and data first, AI as the layer.

4Data strategy: conversion, quality and automation

In this architecture the data strategy is not a supporting workstream, it is the centre. The gap report rated data quality the highest current-state risk and named manual, out-of-system capture as the root cause of duplicate entry and broken trails, alongside unstandardised legacy data. Bringing that data up to standard is therefore not a clean-up after the build, it is the build. This section sets out how existing data, wherever it currently sits, is converted into the owned record and lifted to a quality the architecture can rely on.

4.1 One identifier, one golden record, owned

A single client and entity identifier is enforced across the architecture, and the golden record lives in the owned data layer. This directly answers the finding that the same record is held in two or three systems with no single source of truth. Owning it rather than housing it in a platform is what keeps the Group's data portable and the surrounding tools replaceable.

4.2 Bringing existing data up to standard: the conversion pipeline

Every source the Group holds today feeds one pipeline into the owned record: ViewPoint's SQL back end, Xero, the shared drives, the Excel workbooks that currently act as glue, KYC360, and the documents held across the four digital stores and the physical file room. The pipeline runs in seven stages, and nothing reaches the golden record until it has passed through them.

4.3 The uplift, by data domain

The pipeline is applied domain by domain, in the priority the gap report set. Each domain starts from a known current state and has a defined target, so the uplift can be measured rather than claimed.

4.4 The ingestion layer does the heavy lifting on the backlog

The same ingestion layer that fixes go-forward capture is what makes the historic uplift feasible at scale. Standardisation and de-duplication are largely rules-based, but enrichment is where the AI extraction earns its place: the layer reads the source documents, the passports, trade licences, incorporation papers and prior filings, and pulls the structured fields needed to complete a record. This is the one place the architecture deliberately runs AI on dirty data, because extracting from a messy historic set is exactly how that set gets cleaned. The bulk conversion is a one-time Stage 2 workstream, and the governance stage keeps it clean thereafter.

4.5 Match the automation tier to the task

4.6 AI on clean data, and where dirty data is tolerable

The distinction the proposal drew still governs sequencing. Document drafting can begin before the record is fully clean, because the AI works on the document in front of it, which is why the drafting quick wins can start early. Anything that reads the master data or feeds a regulatory submission waits for the clean identifier. The one deliberate exception is the backlog enrichment in 4.4, where extraction is run on the messy historic set precisely in order to clean it. The data core and the quick wins therefore proceed in parallel, not in sequence.

5To-be workflows for the priority workstreams

The workstreams below are the priority cluster from the gap report's value-against-risk matrix. For each, the current state is the gap report's finding, the target is the design, and the closure paths are tagged in the same scheme. Sizing and sequencing are Deliverable 3.

5.1 Onboarding and KYC CIN

Today. Onboarding is run largely outside systems. It is the heaviest manual load in the Group and the gateway to all revenue, which is why it sat at the top of both axes of the matrix. A single fund can bring twenty or more underlying parties, so the work fans out per entity, and the file cannot progress, and the client cannot be billed, until compliance clears it.

Target. Intake comes in through the KYC360 portal and screening, the ingestion layer extracts and validates the documents and writes the result once into the owned record, with the entity fan-out resolved in the core rather than re-keyed per party. The file note is drafted by AI for a reviewer to complete. This is the flagship because it is where owning the record and automating capture pay back hardest, and it proves the whole design.

5.2 Regulatory compliance and monitoring CN

Today. The compliance calendar is rebuilt manually every year because no system holds its memory, and the monitoring programme runs across well-defined phases by hand.

Target. The calendar and monitoring programme run as workflows off the owned record, so they regenerate and alert rather than being rebuilt. AI drafts the compliance summaries, and the compliance officer's review is retained at every point a regulator examines the output. The team's own process documentation maps the phases, so the workflow lands against a known shape.

5.3 Audit IN

Today. Audit runs in Inflo, but working papers and reports are drafted from templates by hand, and client and entity data is coordinated across systems manually.

Target. Inflo draws client and entity data from the record rather than re-entering it, and the repetitive drafting is produced by the AI layer against the audit templates, freeing time for the judgement work the standards require. Inflo stays as a specialist spoke, and nothing about it is load-bearing.

5.4 Annual accounting and tax CIN

Today. Annual-accounting clients are served manually in Excel: statements posted by hand, trial balances and returns prepared manually, data spread across systems and email. Xero does not cover annual accounting at all.

Target. Two things separate here. Routine outsourced accounting stays on Xero as a specialist spoke, but the design does not lean on Xero's own AI. The Group tested the new AI-enabled version of Xero and the output quality was not good enough to rely on. Instead the ingestion layer prepares and cleanses the data upstream and feeds it in, which lifts quality regardless of the tool and reduces the Group's dependency on Xero's AI to the point where that capability can be turned down to zero, or Xero itself replaced, without disturbing the record. Annual accounting, which Xero cannot do and which is run by hand in Excel today, is a genuine new-capability build: it is produced on the owned record, and it is the second build candidate alongside the core. The tax opinion stays with the professional. The tax lead described the analysis as purely brain, and the design respects that line: AI accelerates the preparation into the opinion, it does not form it.

5.5 Master data and reporting DI

Today. Cross-entity reporting is the biggest finance time sink, most of it spent reconciling ViewPoint and Xero before any number is produced.

Target. With the golden record owned and the spokes integrated, reporting draws from a single reconciled source directly. Bounded, well-defined reports are a natural fit for the internal systems team to own, given its existing SQL capability. The design notes this as an internal-build boundary rather than assuming it.

5.6 Corporate secretarial and renewals CN

Today. Four to five hundred clients carry annual board minutes and renewal filings. Renewals roll forward on reminder logic maintained by duplicating files, and board minutes follow templates but are produced by hand.

Target. Renewal and reminder logic runs as workflow off the owned record, so files are not duplicated to hold a reminder. Board minutes and the standard corporate-secretarial documents are drafted by the AI layer from their templates for review. This is high-volume, predictable, template-bound work, the profile that suits workflow plus drafting best.

5.7 Invoicing and finance operations CI

Today. M/HQ invoices in ViewPoint, Rethink and RAA in Xero, and any Group view of cash requires the two to be merged by hand.

Target. Invoicing runs off the record and Xero, with the integration layer giving a single Group cash view. This closes entirely through configuration and integration, with no new capability, which is why it is a strong early move.

6AI tools integration plan: Co-pilot and Claude

This section is the AI tooling integration plan the RFP and the Deliverable 2 acceptance criteria call for: where the tools are deployed, how teams are trained, how the work is governed, and how it is secured. The framing is the one the ops team asked for: systems and data first, AI as the layer.

6.1 Where each tool is deployed

Both are deployed first against the document-heavy drafting work that recurred in every function, and Claude additionally at the ingestion boundary. That is the deliberate starting point: high consistency, contained risk, and time given back quickly, and it does not wait on the data core being complete.

6.2 Training and adoption

The gap report flagged adoption as a real risk: teams are satisfied with the current ViewPoint and may resist disruption, and it recommended treating adoption as a workstream, not an afterthought. The plan follows that, with role-based training tied to the specific work each function hands to the tools, led with the quick wins that give time back so the first experience is a helpful one. This is the buy-in the Group's leadership asked for in naming AI training and cross-group involvement as a goal of the strategy phase. The adoption sequence and the capability shift are in Section 8.

6.3 Governance

• Human review is retained wherever an external party examines the output. AI drafts, a professional reviews and signs. The compliance officer's review stays in the loop for regulated outputs, as the monitoring-programme documentation already assumes.
• Validation at the ingestion boundary. Extracted data is validated before it reaches the record, so the AI never silently writes to the source of truth. The golden record is protected by design.
• Templates and prompts are owned centrally, and tool and model selection is a governed decision made by the technology forum in Section 9, not ad hoc per team.

6.4 Security

• Sensitive data is handled with care by design. The document review flagged live payroll with names, salaries and IBANs, client financial workings, and UBO and source-of-wealth data. Access to AI tooling over that data is controlled, and the regulated context, DIFC and ADGM, sets the bar.
• Client data is not used to train models, and tenant isolation and data-residency considerations are confirmed at tool selection.
• Access follows role, consistent with the access controls on the owned record.

7The four paths: our recommendation

The proposal set out four paths for closing any gap that needs new capability, and committed to documenting the alternatives for every recommendation. The recommendation here is a data-centric architecture built on an owned core, and it uses all four paths in their proper places.

7.1 The core we recommend building

7.2 The recommendation, by workstream

We state the Path C framing plainly: CrossVal is a technology firm with build capability, not a vendor-neutral advisor, and the recommendation to build and operate the core is disclosed as such, with the platform and internal-build alternatives documented so the Group can validate. The Group retains full discretion on every path.

8Capability evolution framework

This is the human side of the design. Its framing is capability shift and capacity unlock, not headcount reduction. The Group's roughly two hundred people are redeployed against higher-value work as ingestion, integration and workflow absorb the routine, and the operating question is how the Group grows revenue per professional rather than headcount as it scales.

8.1 Three horizons

8.2 How roles evolve

• Onboarding officers move from keying and chasing toward reviewing extracted data and handling the exceptions the ingestion layer surfaces, the judgement in a file, not the assembly.
• Accountants and audit staff move from repetitive drafting toward review and the professional judgement the standards require, with the first pass produced for them.
• Compliance moves from rebuilding calendars and re-running defined phases toward monitoring, escalation and the decisions that need a person.
• The systems team moves toward owning the bounded reporting and configuration on the owned record, a more central role than today, with the key-person dependency the gap report flagged designed out.

None of this is a reduction case. It is the redeployment case the proposal described: the same people, against higher-value work, as the routine is absorbed.

9Operating model and steady state

This section sets out how the architecture is built, run and evolved once Stage 2 is complete. It maps to the RFP's steady state of ongoing improvements with the vendor or with internal teams. It lays out the options, and the choice, and its cost, are the Group's to make with Deliverable 3.

9.1 Three steady-state options

On current evidence the hybrid model is the natural fit, and the architecture makes it safer than a platform would: because the source of truth is data the Group owns, the operating partner can change without the record moving. That is a materially lower lock-in than housing the record inside a vendor's platform. We present hybrid as the recommended option, not the only one, and Deliverable 3 sizes each.

9.2 Governance for steady state

• A standing technology governance forum, Systems-led and sponsored at Group-CFO level, owns tool and model selection, the prompt and template library, and the sequencing of changes.
• Data governance sits at the centre, not the edge. Because the Group owns the record, maintaining the single identifier and the golden record is the core steady-state practice, the thing that keeps the architecture from drifting back to the current state.
• Security governance owns the access, residency and review controls from Sections 6 and 10 rather than assuming them.

10Infrastructure, hosting and security

The architecture in this report is data-centric and cloud-oriented, so the infrastructure question is not how to enlarge the server room but where the owned record is hosted and how it is secured. This section sets the hosting direction, grounds it in the DIFC and ADGM data protection regimes that govern the Group's data, and sets out the estate refresh that is warranted regardless.

10.1 The current estate

MHQ's system of record, ViewPoint, is an on-premise 2019 version, reported in discovery as slow, especially for finance, and carrying a twice-daily backup routine the systems team runs by hand. Files sit across an on-premise NAS and a controlled document room, IT is delivered by a third-party vendor under the operations team, and the IT asset register is kept in Excel. Security today rests on a firewall, Bitdefender and Microsoft tooling, and the team reported four to five targeted phishing incidents last year that had to be notified to the relevant authorities. The estate is aging, on-premise, and thin on in-house engineering, with a six-person systems team alongside the outsourced vendor. The direction of travel is to retire and migrate it, not to invest further into it, which matches the Group's own stated strong preference for a cloud-based model over the current on-premise one.

10.2 The hosting decision: cloud, with the record owned

The owned data core is hosted in the cloud, in a selected region, with the Group owning the data throughout. The AI layer, Co-pilot and Claude, is cloud by nature and consumed as a service, and the systems team already runs a Copilot Studio tool, so the ground is familiar. This keeps the infrastructure light and the estate small, and it follows directly from the architecture in Section 3 rather than departing from it.

10.3 Data residency and what the law requires

The pressure behind the hosting question is real and observed: clients increasingly ask where the Group's data sits, and the security questionnaires that carry those questions are rising in volume and take around five hours each. The question is a regulatory one, and the two regimes that govern the Group's data answer it clearly.

Under the DIFC Data Protection Law No. 5 of 2020, a transfer of personal data to a recipient outside the DIFC is permitted where the destination is judged to have an "adequate level of protection" (Article 26), or, absent adequacy, where "appropriate safeguards" such as the DIFC's standard contractual clauses or binding corporate rules are in place (Article 27), with the processing notified to the Commissioner. The ADGM Data Protection Regulations 2021 mirror this: transfers outside the ADGM rest on an adequacy decision (Article 41), for which the ADGM has adopted all jurisdictions the European Commission recognises as adequate, or on appropriate safeguards such as the ADGM standard contractual clauses (Article 42). Both regimes follow the GDPR model, and, importantly, neither requires data localisation or residency inside the free zone.

The consequence for hosting is direct. Cloud hosting is compliant provided the region or provider sits in an adequate jurisdiction, or the transfer is covered by standard contractual clauses in the data processing agreement, and the transfer is recorded and notified. On-premise hosting inside the DIFC or ADGM is not a legal requirement. The compliant path is to select an appropriate cloud region, put a data processing agreement with standard contractual clauses in place with the cloud and AI providers, use enterprise terms that keep client data out of model training and hold tenant isolation, and document the arrangement in the DIFC notification and the ADGM record of processing.

10.4 Turning security into a commercial asset

Doing this properly does more than satisfy the regulator. A hosting and security posture on a recognised cloud platform, with documented transfers, a data processing agreement and standard contractual clauses, and clear residency answers, is exactly what the rising client questionnaires ask for. Captured once as a reusable security pack, it shortens the roughly five-hour response each questionnaire now takes and removes a recurring point of friction at client onboarding and renewal. The control the regulation requires becomes something the Group can show clients.

10.5 The estate refresh that is warranted

Independent of the hosting direction, part of the 2019 estate needs refreshing, and this is targeted renewal alongside migration, not a data-centre build. The items that matter:

• Endpoints and identity. Refresh the aging device fleet and put single sign-on and multi-factor authentication across the Group, given the phishing history and the move to cloud services.
• Backup and disaster recovery. Replace the manual twice-daily backup routine with managed, cloud-based backup and a tested recovery position, removing both the burden and the risk.
• Network and security tooling. Uplift the current firewall and endpoint tooling to a posture that matches the incident history and the client-questionnaire bar, coordinated with the outsourced IT vendor the operations team already manages.

None of this is a large capital programme, and Deliverable 3 sizes it directionally alongside the rest of the roadmap.

11Dependencies and delivery risks

The gap report carried the current-state risk register and deferred the forward-looking risks to here and Deliverable 3. This register covers the design and delivery risks that follow from the target state, reviewed in the weekly steering check-in.

11.1 Design dependencies

• Ratification of the direction change. This deliverable recommends an owned data core rather than a platform migration, which departs from the agreed acceptance criterion. It needs an explicit decision from the sponsor and the Group Systems lead before the roadmap is built on it.
• Diagram sign-off. The architecture and workflow diagrams are drafts for the Group Systems lead to approve, and the design is provisional until then.
• Spoke API-openness. Each specialist must expose a proper API and be replaceable. Xero and KYC360 do, and any tool chosen for entity or corporate-secretarial work must meet the same test.

11.2 Delivery risk register

AAppendix: assumption log

This log continues the assumption log from the current-state report. The numbering restarts for this deliverable.

End of Deliverable 2. This report sets the future-state design and the operating model. Deliverable 3 sequences and sources the work and frames the investment and the Stage 2 decision.