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 binding constraint has not moved: the main implementation completes before the end of Q4 2026. Working backwards from 31 December, this proposal 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.

4Scope of work: six workstreams

Six workstreams run staggered across the twenty weeks. WS0 opens and gates; WS5 runs the whole way; everything else overlaps by design.

WS0 · Mobilisation and the spoke-platform gate (weeks 1–2)

• Close the entity-management spoke decision (ViewPoint upgrade vs Quantios as a spoke). The direction, an owned core with specialist spokes, is already decided; this gate picks the spoke. Decision paper: the capability matrix in Appendix B of the Stage 1 Future State report, covering the ViewPoint support window (~12 months), the completed KYC360 API on the upgraded ViewPoint, and the ADGM/DIFC jurisdiction gating on Quantios reporting.
• Lock the data model, tenancy design and segregation boundary for R&C client data, signed off by the Group MLRO before build.
• Baseline capture: time-and-motion sample across onboarding, renewals, invoicing, reporting, audit file prep. This is the measurement framework: no benefit is claimed in this proposal that is not measured here first.
• Environments, access (ViewPoint SQL, Xero, KYC360, document stores), security review, and the Stage 2 RAID log.
• Output: signed architecture and data model; spoke decision closed; baseline measurement pack; Release 1 backlog.

WS1 · Data foundation (weeks 2–12)

• 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–16)

• KYC360 onboarding module deployed for intake, 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 into ViewPoint/Xero).
• Output: intake and BAU changes captured once, entered once.

WS3 · Spoke configuration and integration (weeks 4–18)

• Configure the chosen spoke platform; migrate; UAT.
• Integrations: spoke platform to owned record; KYC360; Xero; ComplyAdvantage; Inflo; BlueSky.
• Payroll flow (Excel to HRMS to Xero) 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 6–20)

• 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.
• AI tooling: prompt library per function, an AI usage and governance policy, security review, and hands-on training. 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–20, continuous)

• Change and adoption programme by function; champions network; department-level KPIs.
• Training and education phase (weeks 12–20, 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 31 December backstop. Scope flexes; the date does not.

The windows overlap deliberately: each release starts while the one before it is still closing, which is what keeps six workstreams inside five months. The gate dates (25 Sep, 27 Nov, 18 Dec) are the commitments; the start dates are indicative until WS0 planning locks the backlog.

7Quick wins: the first eight weeks

Named, dated, and owned. These are chosen because they carry no dependency on the WS0 spoke decision, and they are weighted deliberately toward the finance and compliance work where Stage 1 evidenced the heaviest manual load.

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. 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 October the emphasis shifts to training, education and handover, and by December 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

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.

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

From January 2027: the Group runs day-to-day; CrossVal provides a defined support and improvement model (options: hypercare only / hypercare plus managed improvement / full managed service, priced separately). The Master Data Architect owns the data layer. The improvement backlog is governed by a quarterly technology forum. The internal systems team holds its standalone technology seat, and if the Group elects to internalise the core, the hiring and capability plan from WS5 governs the handover.

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.