Stage 2 Proposal: Implementation

1Where we are

Stage 1 delivered three documents (current-state and gap report; future-state technology strategy and operating model; transformation roadmap) and a review cycle that produced 23 points of written feedback from the Group, all of which were resolved and shipped into the revised deliverables on 14 July 2026. The direction is settled: the Group's problem is not the absence of a system of record; it is that data reaches the system of record by hand. Stage 2 builds the layers that fix capture, hold the Group's own master data, and put automation and AI on top of it. The specialist systems stay, as swappable spokes around a record the Group owns.

The programme completes before the end of February 2027. The close was moved from 31 December at the Group's 15 July review, to reduce delivery risk and to respect the Group's bandwidth through 1 October. The plan is sized for a start no later than Monday 3 August 2026.

2Objectives

3Target architecture

Read the architecture from the centre out, not top to bottom: the owned data core is the source of truth, and everything else is either an input to it, a spoke around it, or a layer on top of it. This is the same architecture the Stage 1 Future State report set as its central theme, carried forward unchanged into the build.

And read left to right, the same architecture is a single flow: data enters once at the boundary and moves out to every tool and report without ever being re-keyed.

Hosted in the region, portable by design

The owned core runs on a sovereign stack hosted in the region: UAE preferred, with options in Saudi Arabia, Oman and Abu Dhabi, and backups split between Dubai and Abu Dhabi. The architecture is built sandbox-first and deployed plug-and-play, so it can move between regional data centres without rework; that same portability is why the quick wins are not blocked by any hosting decision. Running costs (hosting, storage on AWS or MongoDB-class platforms, AI models and token usage, and tenancy) are set out in a separate cost note, with one-time and recurring costs distinguished and the capex and opex candidates flagged, so there are no budget surprises later.

4Scope of work: six workstreams

Six workstreams run staggered across the thirty weeks. WS0 opens with the systems evaluation and the baseline; WS5 runs the whole way; everything else overlaps by design, and the heavier Group-side work is scheduled after the bandwidth constraint lifts on 1 October.

WS0 · Systems evaluation, selection and mobilisation (weeks 1–4)

• One evaluation framework, four tool categories: entity management, CRM, accounting, and compliance screening (KYC360 vs ComplyAdvantage, taken as an early decision). Every candidate is scored on the same tests, interoperability first, so the selected tools' APIs speak the same language and nothing is chosen in sequence that mismatches later. The direction, an owned core with specialist spokes, is already decided; WS0 picks the spokes.
• ViewPoint is a contender, not the default. Candidates are benchmarked against it, with its known constraints on the table: the support window (~12 months), the missing API infrastructure that gates customisation, and the completed KYC360 API on the upgraded version. The Stage 1 capability matrix (Appendix B of the Future State report) is the starting decision paper.
• Two weeks of technical benchmarking inside a four-week selection window: the technical work completes in the first fortnight; the second fortnight carries the demos, reference calls and decisions at the pace the team's availability allows. Selection closes Friday 28 August.
• Kickoff in the first week of August: a consolidated kickoff presentation, and a baseline time study that repeats the end-to-end onboarding observation from discovery (measured then at roughly 12 hours of client time) under the WS0 measurement framework, alongside time-and-motion samples across regulatory compliance, corporate secretarial, audit, tax and accounting work. No benefit is claimed in this proposal that is not measured here first.
• A parallel data kickoff with the Group's data team, to align on the prior two months of data work, naming fixes, the client card definition and the client tape outputs.
• Lock the data model and the tenancy design: the segregation boundaries for R&C client data and for audit data, signed off by the Group MLRO before build.
• Environments and access to today's estate (ViewPoint SQL, Xero, KYC360, document stores), security review, and the Stage 2 RAID log.
• Output: systems selected across the four categories; signed architecture and data model; baseline measurement pack; Release 1 backlog.

WS1 · Data foundation (weeks 2–20)

• Master data model build; owned record deployed (segregated tenants).
• Legacy CRM cleanse and standardisation (the "Ltd. vs Ltd" problem), de-duplication, unique party ID applied Group-wide. The ID already exists for M/HQ in ViewPoint; this workstream extends its enforcement to Rethink-only and RAA-only clients, including the connected parties (UBO, shareholder, officer) that are not recorded today.
• Migration and reconciliation; data quality dashboard and ongoing stewardship rules.
• Output: Group master record live, with a measured data-quality score against the Stage 1 baseline.

WS2 · Capture and ingestion layer (weeks 3–24)

• WS2 does not wait for WS0. The ingestion build starts in parallel against defined interface contracts: a spoke-agnostic write model, the required data points agreed by process of elimination, and connectors bound to whichever tools WS0 selects. Tool selection changes the connector, not the layer.
• Screening-led intake deployed for onboarding, periodic review and ownership/control changes, with BAU document flow (email-received documents) routed through the same layer.
• OCR and validation: keyed data checked against source PDFs before anything writes to the record.
• Straight-through write to the owned record and onward to the spoke platform.
• Fee-approval-to-invoice automation (removes the line-by-line re-keying between the entity-management and accounting systems).
• Output: intake and BAU changes captured once, entered once.

WS3 · Spoke configuration and integration (weeks 6–26)

• Configure the spokes selected at WS0; migrate; UAT (the heavier Group-side testing is scheduled after 1 October).
• Integrations: the selected entity-management spoke to the owned record; the selected screening tool; the accounting tool of choice; Inflo; BlueSky.
• Payroll flow (Excel to HRMS to the accounting tool) rebuilt so individual employee changes no longer require a full payroll rollback.
• Output: integrated landscape, no manual bridge files.

WS4 · Workflow automation and the AI layer (weeks 8–29)

• Document production: working papers, board minutes, corporate governance documents, structuring proposals (including the PowerPoint-to-HTML proposal change flagged in the Stage 1 review; tested for real productivity gain before it is committed).
• Renewals and filings: auto-roll of next-year filings, monthly renewal reporting.
• Compliance calendars generated from jurisdiction rules rather than rebuilt by hand.
• Annual accounting build on the record (no specialist tool covers it; a bounded build per the Stage 1 Future State report, Section 7.1): statement preparation off prepared data toward the team's own 8-to-4-hour goal, and FTA-compliant VAT/CT return generation, with the opinion staying with the professional.
• Fiduciary reviews (elevated to the ranked list in the Stage 1 review on risk grounds): bank-statement requests, review file notes and fee schedules as workflow and AI drafting off the record, human-reviewed at every point a regulator examines.
• Regulator and management reporting from the owned layer.
• Prompt library per function: regulatory compliance (authorisation policies and procedures, for example ADGM applications that today absorb 80 to 120 senior hours each, built from patterns in regulator-approved cases); tax advisory opinions; structuring advisory opinions; tax working papers and the audit (RA) items agreed at the 15 July review. Each library carries a usage governance policy, a security view, and a self-teaching feedback loop that folds reviewed outputs back in.
• AI tooling: hands-on training per function on the libraries and policy. The specific assistant platform (candidates include Microsoft Co-pilot and Anthropic Claude) is selected once the prompt libraries and policies are proven in use.
• Output: automation live in the functions where Stage 1 evidenced the load.

WS5 · Adoption, capability and steady state (weeks 1–30, continuous)

• Change and adoption programme by function; champions network; department-level KPIs.
• Training and education phase (weeks 20–30, led by the dedicated Training and Education Specialist): role-based curricula per function, hands-on workshops for the AI tooling and each new workflow as it goes live, train-the-trainer for the internal systems team and the champions network, quick-reference guides, and completion tracked per department so adoption is measured, not assumed.
• Role and job-description changes; capability framework.
• Recruitment support for the Group-side roles (Section 9).
• Steady-state operating model, support model, and handover pack, including the standalone technology seat and internalisation plan conditions from the Stage 1 Roadmap, restated in Section 9 of this proposal.
• Output: the Group runs it; CrossVal supports rather than drives.

5Deliverables and dates

6Release plan and timeline

Three gated releases, back-solved from the end-of-February close. Scope flexes; the date does not. A quick-wins checkpoint on 18 September shows working automation early; the R1 payment gate sits on 30 October, after the Group's bandwidth constraint lifts.

The windows overlap deliberately: each release starts while the one before it is still closing, which is what keeps six workstreams inside seven months. The gate dates (30 Oct, 29 Jan, 26 Feb) are the commitments; the start dates are indicative until WS0 planning locks the backlog, and the December holidays are inside the R2 window, not squeezed against a year-end close.

7Quick wins: the first ten weeks

Named, dated, and owned. These carry no dependency on the WS0 systems selection, they are deliberately light on Group-side effort while bandwidth is constrained, and they are weighted toward the accounting, finance and compliance work where the time savings are largest. All are live before the 18 September checkpoint or the 30 October gate.

The compliance savings are counted honestly: a good share of the time these tools free is deliberately reinvested into review quality rather than removed, which is exactly where the Group wants it.

8Resourcing: CrossVal team

Ten specialists across the engagement: the build team surges through mobilisation and the core build, and a dedicated training and education phase carries the later weeks, tapering as the Group's own team takes over. The thirty-week window spreads the same hours more thinly than a year-end close would have, which is deliberate: it fits the Group's reduced bandwidth through 1 October and keeps the December holidays inside the plan rather than against it. Role hours are the indicative allocation within the fixed fee envelope; the final cut is locked at contracting against the WS0 backlog.

The build team is at full strength through mobilisation and the early build; from December the emphasis shifts to training, education and handover, and by February the Group is running the system with CrossVal in light support. The taper is the handover working.

9Resourcing: Group side

The Group's project team (no fee, as allocated by the Group):

In addition the Group provides a named data owner per entity, function SMEs for design and UAT, and Group MLRO / compliance sign-off. Greg, as sponsor, turns decisions around inside 48 hours.

The hybrid-model conditions (from the Stage 1 Roadmap, Sourcing recommendations). The internal systems team (six people, currently reporting through Group Finance) takes ownership of bounded reporting and configuration on the record. Two conditions attach. First, the team needs a standalone technology seat rather than reporting through Finance; this is an operating-model change to make in Stage 2. Second, if the Group wants to internalise the core over time, Stage 2 carries an explicit hiring and capability plan for that team, sized so the handover is real rather than nominal.

The Group-side hires: four raised by the Group, one proposed by CrossVal

The Business Process Transformation Lead, defined

• A hands-on doer, not a coordinator: someone who changes how teams fundamentally operate, for example ensuring ADGM submissions run through the approved prompt libraries, with no sensitive data exposed, and outputs reviewed within set SLAs.
• Credible with senior managers: able to engage function heads directly and change working methods at their level, not only below it.
• Engaged from day one of Stage 2: involvement across the whole effort, identifying use cases early rather than arriving after the build.
• Grows into running the technology team: reporting to the owners rather than through Finance, with Geetu as the number two.
• Large-organisation digital-transformation experience: has carried operating-method change through an organisation of real size before.
• Distinct from change management: this role changes the operating method; the Change Management and Adoption Lead changes the culture around it. They are different jobs.

Reporting line. Technology reports to the owners, not through Finance; this is the standalone technology seat from the Stage 1 recommendation, made concrete. In the target model the Business Process Transformation Lead runs the technology team with Geetu as the number two; during Stage 2 the CrossVal engagement principal acts as the interim gatekeeper, separating mission-critical needs from noise.

10Governance and ways of working

• Steering committee (monthly). Greg (sponsor), Serena (project manager), Geetu (Systems lead), CrossVal engagement principal. Owns the release gates, the RAID log's high items, and the scope-flex decisions that protect the Q4 date.
• Delivery oversight (weekly). CrossVal delivery leads with Serena and Geetu, and function-head representation as the agenda requires. Tracks the release plan, clears blockers, reviews the measurement dashboard.
• Day-to-day delivery. CrossVal build team working alongside the Group implementation team (Ateeq, Geetu, Raja) with Anna, Deepthi and Charu as function anchors; decisions inside 48 hours via Greg.

Decision rights, escalation path and the RAID log are set in the WS0 mobilisation pack. Scope flexes; the date does not.

11Measurement framework

No projected savings appear in this proposal. Instead: WS0 captures a measured baseline (volumes, cycle times, touch counts, error and rework rates) across onboarding, renewals, invoicing, reporting and audit file prep. Targets are set against that baseline at the end of WS0 and reported monthly. The post-implementation report in January 2027 measures the same things the same way.

The Group's own observed figures from Stage 1 discovery are the calibration points, and each carries its source. These are validation targets the measurement framework tests, not benefits we claim.

12Fees and payment schedule

CrossVal fees

• Fees: AED 1,335,840 (fixed envelope; USD 363,741 at 3.6725), invoiced against the milestone schedule below. Hours are logged and reported for transparency, but the fee does not float with them.
• Less Stage 1 credit: (AED 132,210, being USD 36,000 at 3.6725), applied against the first invoice per the Stage 1 engagement terms.
• Net: AED 1,203,630 (USD 327,741 at 3.6725)
• Change budget (optional, drawn only against approved change requests): up to AED 133,584 (10% of the gross fee)
• Steady-state operate (hypercare, managed improvement or full managed service from January 2027) is contracted and priced separately, and runs as opex.

Overage and ceiling

The fee is fixed, so estimation risk sits with CrossVal, not the Group. The hour mix across roles will move as the work reveals itself, and misestimation up to 15% of the envelope is absorbed by CrossVal before any change request is even contemplated; in Stage 1, CrossVal absorbed an overage of roughly 18% and focused on outcomes rather than the hour mix, and the same posture carries into Stage 2. Change requests are reserved for genuine scope additions, such as specialist systems or equipment agreed after signature, and draw only on the optional change budget. That budget is also the ceiling: the Group's total exposure cannot exceed the fixed fee plus the change budget without a new signature.

Capex and opex: how the fee can be structured

The fee splits naturally into build and run, and the Group can elect to treat the two differently in its accounts.

The tools and AI setup is deliberately scoped to include both possibilities: the one-off setup elements are priced and invoiced as distinct deliverables so they can be capitalised if the Group elects to, while the recurring licence and usage costs run as opex. Final treatment is a Group accounting decision to take with its auditors under the applicable standards; CrossVal will structure the invoicing and the deliverable definitions to match whichever treatment the Group chooses, locked in the WS0 mobilisation pack.

Payment schedule

Percentages of gross fee; the Stage 1 credit is netted in milestone 1; the schedule recalculates if fees change.

Exclusions

Third-party software licences and vendor implementation fees; hardware; recruitment agency fees for Group hires; salaries of Group staff; data migration of records outside the agreed scope; ongoing run and support beyond the steady-state handover (priced separately); anything arising from a change of the spoke-platform decision after the WS0 gate.

13Risks and mitigations

14Steady state and ongoing services

From March 2027 the Group runs day-to-day. The data-architecture owner (Geetu, developed under the Master Data Architect's learning plan) owns the data layer; the improvement backlog is governed by a quarterly technology forum; the technology team holds its standalone seat reporting to the owners; and if the Group elects to internalise the core over time, the hiring and capability plan from WS5 governs the handover.

Beyond the handover, CrossVal can provide ongoing services in whatever combination fits. The catalogue, so future commercial planning has something concrete to work from:

Indicative ranges for these follow in the cost note, so they can be read alongside the hosting, storage and AI running costs rather than in isolation.

15Next steps

AAppendix: assumption log

Continues the assumption-log convention from the three Stage 1 deliverables; numbering restarts for this proposal.

BGlossary: key terms and acronyms

The engagement and its documents

The architecture

The systems

Acronyms

End of proposal. Prepared by CrossVal for the M/HQ Group. The next step is the review conversation in Section 15.