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

• One master record per client and per connected party across the Group, replacing entity-by-entity re-keying, and covering the Rethink-only and RAA-only clients that today never fully reach the entity-management system.
• Automated capture. Intake, screening and document data land in the record without manual entry. Manual data entry becomes the exception with a reason attached.
• Quick wins live inside eight weeks. The Group sees working automation before the core build lands.
• An AI layer where it earns its place. Document production, reporting and drafting; not where judgement is the product (tax opinions, audit conclusions).
• A Group that can run this without us. Trained teams, defined roles, documented systems, and a steady-state model agreed before we leave.

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.

4Scope of work: six workstreams

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 Deliverable 2 Appendix B, 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 Deliverable 2 §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.
• Co-pilot and Claude: licences, deployment, prompt library per function, governance and security policy, and hands-on training.
• 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.
• 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 Deliverable 3 §6.
• 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.

7Quick wins: the first eight weeks

Named, dated, and owned. These are chosen because they carry no dependency on the WS0 spoke decision.

8Resourcing: CrossVal team

Roughly 3.3 FTE across 20 weeks.

9Resourcing: Group side

Required from the Group (no fee): the internal systems team led by Geetu confirm name; a named data owner per entity; function SMEs for design and UAT; Group MLRO / compliance sign-off; a nominated executive sponsor for decisions inside 48 hours.

The hybrid-model conditions (from Deliverable 3 §6). 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 four roles the Group raised confirm against Greg's email of 28 Apr

10Governance and ways of working

• Steering committee (monthly). Executive sponsor, Group 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 the Group Systems lead 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 internal systems team and named SMEs; decisions inside 48 hours via the nominated sponsor.

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.

12Investment and payment schedule

CrossVal fees

• Fees: USD 545,000 placeholder: reprice with the rate card, billed hourly against a logged timesheet at the Section 8 rate card, capped per release.
• Less Stage 1 credit: (USD 36,000) confirm credit amount and mechanism against the signed Stage 1 engagement terms, applied against the first invoice.
• Net: USD 509,000 recalculates with the two items above
• Change budget (optional, drawn only against approved change requests): up to USD 54,500 placeholder: 10% of gross; confirm

Third-party costs: client-contracted, not in the CrossVal fee

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. Populate at design time; carry forward at minimum: Group-wide scope; 3 August start; observed figures treated as stated by function heads, not independently verified; vendor pricing confirmed at WS0; hybrid-model conditions as per Section 9.

BAppendix: Stage 1 feedback, closed and carried

Closed and shipped in the revised deliverables (14 July 2026), not to be re-argued

• Origination (not "onboarding") starts at M/HQ; each entity onboards and screens its own clients separately. Corrected throughout the deliverables.
• Fiduciary re-prioritised into the ranked use cases (item 8) on risk grounds; prioritisation stated as risk-weighted, not volume-weighted.
• R&C client data segregation designed as a separate tenant with firewalls between tenants (wording locked in Future State §5.1b and §7.2).
• Complyfin removed; the R&C function uses the internal ComplyAdvantage instance.
• CRA workflow correction: ViewPoint auto-assigns review dates; the manual load is the email data requests and the human input layer.
• Data-quality scoring basis note added; Uniqueness raised, Lineage lowered, on the evidence.

Genuinely open, carried into Stage 2

• The spoke-platform decision (ViewPoint upgrade vs Quantios as a spoke), including whether the completed KYC360 API on the upgraded ViewPoint changes the calculus. Closed at the WS0 gate using the Future State Appendix B capability matrix.
• The PowerPoint-to-HTML proposal-production change: tested in WS4 before any productivity gain is claimed.
• Confirmation of the third-party cost lines and any vendor pricing changes (WS0).

CVerification register

Clear these before this document is designed and issued. Everything not listed here is anchored to the Stage 1 deliverables and needs no further check: the USD 450/hr principal rate, the Q4 2026 backstop, ~USD 111k total licences, ~1,200 entities, ~200 staff, ~72% of payroll in the priority cluster, and all observed figures in Section 11.

End of draft v0.2. Working document for internal review. Not for issue until the verification register is cleared and the document is designed.