CONTENTS

• ·Executive summary3
• 01Cover note4
• 02Engagement context5
• 03Approach to Stage 1: Tech Strategy7
• 04Stage 1 deliverables11
• 05How we will work12
• 06Commercial model14
• 07Stage 2 and steady state15
• 08Team and credentials16
• 09Next steps17
• AAssumption log18
• BRisk register19

Executive summary

A strategy and roadmap engagement, structured for a Q4 2026 implementation deadline.

CrossVal proposes a Stage 1 Tech Strategy engagement that produces the strategy, roadmap, and operating model the Group needs to commission Stage 2 implementation with confidence, on a timeline that completes implementation before end of Q4 2026.

The frame

The Group's stated goal is to move from fragmented manual work to intelligent, connected operations, with accuracy, governance, and scalability as the operating priorities. Stage 1 produces the strategy and roadmap that gets the Group from the current state to that target.

The shape of the work

A technology strategy built systems-first, with AI added where it does something the existing platforms cannot. Quantios is treated as the system of record. AI, Co-pilot, Claude, and custom build are reserved for gaps that configuration and integration cannot close. Data quality is treated as its own workstream because it is a precondition for everything downstream.

Six workstreams plus synthesis

Systems landscape, integration architecture, data quality, functional and control gap analysis, targeted AI and tools assessment (including Co-pilot and Claude), and role, function, and adoption analysis. Two synthesis outputs follow: the Stage 2 transformation roadmap with investment framing, and the operating model for steady state.

What is different about us

CrossVal is built to be a long-term technology partner, not a project advisor. Stage 1 is the start of a partnership across architecture, build, and ongoing operation. Most advisory firms in this space deliver a strategy document and exit. We design the architecture, build what needs building, and stay to operate it. That structural commitment is what allows the Group to move into the steady state described in the RFP with the same partner.

01Cover note

Thank you for the early sight of the refined RFP. The methodology in this proposal is structured directly against the Stage 1 scope as you have defined it, and the deliverables mirror the list in the RFP point by point.

A few things to flag up front.

Alignment. The RFP's six scope items (current and target systems review, integration architecture, gap identification, AI assessment, Co-pilot and Claude integration and training, data quality) map cleanly to the six workstreams in our methodology. The six deliverables in the RFP map to the five primary deliverables in section 4, with explicit treatment of as-is/to-be workflows, prioritised use cases, governance, and investment framing.

One deliberate change to the sequence. The RFP lists data quality as the sixth scope item. We treat it as the third workstream, ahead of gap analysis. The reason: gap analysis depends on knowing what state the data is actually in. Putting data quality earlier produces better gap classification and a more credible Stage 2 roadmap. The deliverables to the Group are the same; the sequencing inside Stage 1 is what changes.

On Quantios. We have aligned the methodology to treat Quantios as the system of record, consistent with where the team is heading. The integration architecture, gap analysis, and AI assessment are all built in support of the Quantios deployment rather than alongside it.

On the Q4 2026 implementation deadline. This shapes the Stage 2 roadmap directly. Stage 1 produces a roadmap sequenced to finish implementation in the available window, which will require ruthless prioritisation. We flag this here because it changes how some Stage 2 recommendations get framed, and we want to be transparent about it from the start.

Stage 1 is the start of that partnership. The commercial model reflects this: Stage 1 fees credit against Stage 2 implementation fees if the Group proceeds with CrossVal. The steady state described in the RFP, where the Group moves to ongoing improvements with vendor or internal teams, is exactly the structure CrossVal is built to provide.

Our vision

CrossVal exists because most technology sold into professional services firms targets the wrong thing. The economic centre of gravity is the labour base, not the software stack, and that is where value compounds or fails to. Our view is that technology should be a force multiplier on the firm rather than a replacement for it: clients buy outcomes, and the firms that grow revenue per professional rather than headcount linearly are the ones that treat technology as operational leverage on their own services. We are built to deliver that leverage as a long-term partner that designs, builds, and operates the stack, not as a vendor that hands off a strategy and exits.

02Engagement context

This section sets out our read of the situation drawn from the materials shared and the refined RFP. It is the basis for the methodology in section 3.

2.1What we understood from the materials

Group structure: three legal entities, one operating Group

Visa jurisdictions in scope

Operating scale

Eleven functional workflow areas are documented as needing redesign: lead management, corporate secretarial, invoicing, compliance and ID management, accounting and tax, audit operations, HR and recruitment, marketing, systems and data, private banking, and finance operations.

The Group is mid-transition from ViewPoint to Quantios as the core platform. Concurrent with that, the Group is evaluating additions to the onboarding and accounting stack, including the new Xero release with AI-enabled UAE tax capabilities, and the integration of Co-pilot and Claude as part of the AI tooling layer.

2.2Our read of the situation

The economic frame for technology investment is operational scalability against the labour base, not software cost reduction. Annual software spend is around $111K. Annual payroll is around $9.93M. Value creation in this engagement is measured against how the technology stack changes the productivity of 193 people, not against software consolidation.

Quantios is the architectural anchor. We treat the Quantios deployment as the system of record across the entities and workflows it covers, and structure the rest of the technology architecture in support of it.

The system landscape is fragmented at the integration layer. Most functional areas have a deployed platform, but the connections between them are largely manual. A meaningful share of operational hours goes to handoffs between systems, not work within any single system.

Inter-entity client servicing shows up in onboarding, corporate secretarial, billing, and master data management. Addressing it once at the architecture level has compounding effects across the workflow inventory.

Data quality is a stated concern in the RFP and a likely constraint on what AI and automation can deliver. Stage 1 treats data quality as a precondition workstream rather than a downstream consideration.

2.3The Q4 2026 implementation constraint

The RFP sets implementation completion before end of Q4 2026 as a target. This shapes Stage 1's roadmap directly.

Stage 1 produces a roadmap sized to fit the available window, with deferred items documented for future cycles.

2.4How we propose to approach it

A technology strategy with AI as an operational layer, sequenced as follows: understand the existing and planned systems landscape, map the integration architecture, establish data quality state, identify the gaps that systems and integration cannot close, assess where AI and tools (including Co-pilot and Claude) genuinely add value, and frame the operating model and adoption approach.

The sequencing is deliberate. AI and custom development go to genuine capability gaps rather than to problems that existing or planned systems can already solve through configuration, integration, or scheduled deployment. Data quality issues get surfaced and treated before they undermine downstream analysis or implementation.

03Approach to Stage 1: Tech Strategy

CrossVal's Stage 1 methodology is six sequenced workstreams plus two synthesis outputs. Each step depends on the output of the one before it, and each maps directly to an RFP scope item.

Methodology: six sequenced workstreams

The methodology delivers against the six RFP scope items: Step 1 covers systems review, Step 2 integration mapping, Step 3 data quality (sequenced ahead of gaps as flagged in the cover note), Step 4 gap identification, Step 5 the AI assessment plus Co-pilot and Claude integration and training, and Step 6 the role, function and adoption framework supporting rollout.

3.0Step 0: Kickoff and measurement framework alignment

Before substantive analysis begins, we agree formats and acceptance criteria for the deliverables that follow. This is a working session that covers what we measure, how we measure it, the format the gap register and integration architecture take, and what acceptance looks like for each Stage 1 deliverable.

This step exists because the value of the Stage 1 output depends on the Group reading the measures the same way we present them. Without alignment up front, the deliverables are open to contestation at the end.

3.1Step 1: Current and target systems landscape review

We inventory every deployed and planned platform across the Group: Quantios (and the current ViewPoint state during migration), Xero, KYC360, ComplyAdvantage, Inflo, Blue Sky, RISK Screen, Complyfin, and the network folder structures used for unstructured data.

For each platform we document capability against design intent, current configuration state, license utilisation, known limitations, and integration surface.

We focus particular attention on the Quantios deployment scope: which entities are in scope, which workflows it will support, what Quantios delivers natively, and what the Group expects to build around it. Same approach for the new Xero release and the KYC360 onboarding module if relevant.

This step establishes ground truth on what existing and planned systems already deliver. The gap analysis later is anchored in fact rather than assumption.

3.2Step 2: Integration architecture mapping

We map the target integration topology across the platforms inventoried in step 1.

This includes:

• System-of-record assignment for each major data domain (entity master, client master, transaction data, compliance status, document storage, regulatory filing status)
• Existing API connections and data flows
• Integration gaps where data is currently moved by hand, file export, or re-keying between systems
• Cross-entity data flows specific to the M/HQ to Rethink/RAA handoff

The output is a target integration architecture with current-state and target-state views, plus a register of integration gaps.

3.3Step 3: Data quality assessment

We assess the current state of data across the Group with a focus on the data domains that matter most for downstream decisions: entity master data, client master data, compliance status data, and the data that flows across the M/HQ to Rethink/RAA handoff.

What we do:

• Sample-based assessment of data quality in priority domains (completeness, consistency, duplication, validity)
• Identification of data quality gaps that materially affect Stage 2 implementation feasibility
• Recommended approach for data cleansing, including what gets done in Stage 1, what gets folded into Stage 2 implementation, and what becomes a steady-state data governance practice
• Implications for AI tooling: which gaps can be closed by AI on dirty data, which require clean data first

This workstream sits ahead of gap analysis because data quality is a precondition. A gap register that does not factor in data state produces an unrealistic roadmap.

3.4Step 4: Functional and control gap analysis

We take the integrated systems landscape from steps 1 and 2 and the data quality state from step 3, and overlay the eleven documented workflow areas plus relevant control domains (regulatory, audit, financial reporting).

For each workflow we classify gaps by closure path:

• Configuration of existing tools
• Integration between existing tools
• Data quality intervention
• New capability required (which feeds step 5)

The output format is agreed in step 0 so the Group can read the classification consistently. Gap sizing uses observed data where available (system extracts, sample workflow shadowing) and self-reported time allocation where observed data is not accessible. The methodology used for each gap is labelled clearly.

This step also produces the prioritised use case list required by the RFP: gaps where new capability is justified, with rationale, sequenced by impact and dependency.

3.5Step 5: Targeted AI and tools assessment

For the residual gaps from step 4 that need new capability, we assess closure against four paths:

Each recommendation includes the rationale, the alternative paths considered, and the basis for the chosen path. We state the four-path framing explicitly because CrossVal is a technology firm with build capability, not a vendor-neutral advisor; transparency about that is more useful than claimed neutrality.

This step produces the AI tooling integration plan, including Co-pilot and Claude deployment approach, training framework, and governance and security considerations as required by the RFP.

3.6Step 6: Role, function, and adoption analysis

This workstream looks at the human side of the equation that steps 1 to 5 examine on the systems side, and builds the adoption and training framework the RFP calls for.

What we do:

• Review the existing organisational chart, headcount and payroll file, and available job descriptions
• Targeted conversations with department heads on team composition, role responsibilities, and where time concentrates
• Identify role-level and function-level patterns where technology could shift work between humans and systems
• Frame the operating model implication: what each function looks like in two to three years if the technology architecture and tools from steps 1 to 5 are in place
• Build the adoption and training framework: how teams across the Group are brought into the AI tooling rollout, what training looks like, what buy-in mechanisms are needed, and how the Group moves from current operation to target operation without losing productivity in transit

The framing is capability shift and capacity unlock, not headcount reduction. The output describes how the Group's existing 193 people get redeployed against higher-value work as automation and integration absorb routine work, where the operating model itself needs to evolve as the Group scales toward higher revenue per person, and how the rollout brings teams along rather than imposing change on them.

3.7Synthesis: Transformation roadmap and Stage 2 scoping

A costed Stage 2 implementation roadmap with sequencing, dependencies, and resource requirements, sized to complete implementation before end of Q4 2026.

The roadmap deliverable includes:

• Prioritised use cases with rationale
• Phased roadmap with dependencies and assumptions
• Investment framing: directional cost ranges for each Stage 2 workstream, including third-party technology costs
• ROI expectations: directional value framing, anchored on labour-base productivity rather than software cost reduction
• Sourcing recommendations: what gets resourced internally, what sits with CrossVal as long-term partner, what is vendor-managed

3.8Synthesis: Operating model and steady-state structure

The recommended operating model for how technology is built, run, and evolved post-Stage 2. Governance structure for ongoing technology decisions, including data and security governance. Resourcing model for in-house, long-term technology partner, and vendor-managed components.

This deliverable maps directly to the RFP's "steady state of improvements and optimizations with the vendor or with internal teams" language. The Group has the choice of running steady state with CrossVal as embedded partner, with internal teams (potentially hired during Stage 2 if the strategy recommends this), or with a hybrid model. The deliverable lays out each option with implications.

04Stage 1 deliverables

The deliverables map directly to the RFP's named deliverable list. Each is defined with acceptance criteria.

Supporting appendices: assumption log, risk register.

05How we will work

5.1Engagement model

• Senior-led delivery, with the engagement leadership engaged across the work
• Weekly steering check-ins with the Group's designated lead
• Weekly progress notes circulated to the engagement steering group
• End-of-Stage review session for full deliverable walkthrough

5.2Stakeholder access required

To deliver against the deliverables in section 4:

• Discussions with partner and director level stakeholders across M/HQ, Rethink, and RAA leadership
• Working sessions with the Group Systems team
• Targeted conversations with department heads for the role and function analysis and adoption framework
• Permission to engage selected vendor calls (Quantios, KYC360, Xero) where useful for capability assessment
• Read access to existing systems for capability and configuration review
• Sample data extracts for baselining where applicable, and for the data quality assessment in step 3

5.3Methodology principles

We state these explicitly because they are what separate Stage 1 from a strategy paper.

5.4Assumptions

See Appendix A for the full assumption log. Key assumptions:

• Quantios deployment timeline and scope is sufficiently defined for Stage 1 to map architecture against it
• The Group can make available the stakeholder access defined in 5.2 within the engagement window
• Read access to systems and sample data extracts can be provided under appropriate confidentiality terms
• Stage 2 scope is informed by Stage 1 output but not pre-committed
• The end-of-Q4-2026 implementation deadline is treated as the target; the roadmap may flag elements that are deferable beyond that date if scope cannot be sensibly compressed

5.5Risks and mitigations

See Appendix B for the full risk register. Key risks:

5.6Out of scope

Stage 1 does not include:

• Implementation work. Stage 1 produces a Stage 2 plan, not Stage 2 outputs
• Negotiation with or selection of new third-party vendors beyond capability assessment
• Modification or configuration of any production system
• Data cleansing execution. Step 3 produces the assessment and approach. Cleansing itself is a Stage 2 activity
• Detailed cost build for vendor-licensed software beyond directional pricing for the roadmap
• Audit, regulatory, or legal opinion on compliance positions
• Detailed individual role design. Stage 1 produces operating-model-level recommendations. Role-level design sits with Stage 2 if commissioned

06Commercial model

Commercial terms for Stage 1 were finalised directly with the Group and evolved from the figures originally proposed here. Current terms, effort, and invoicing are recorded in the Stage 1 Project Plan, not reproduced in this document.

6.1What converts Stage 1 to Stage 2

• Approval of the Stage 2 roadmap by Group leadership
• Agreement on Stage 2 scope and commercial terms based on Stage 1 output
• No automatic obligation. The Group remains free to take Stage 1 output and engage a different partner for Stage 2, defer Stage 2, or pursue an internal-led implementation as the operating model recommendation may suggest

07Stage 2 and steady state

Engagement arc: from Stage 1 to long-term partnership

7.1What Stage 2 looks like

Stage 2 is the implementation of the Stage 1 roadmap, sized to complete before end of Q4 2026. Likely a multi-month programme spanning architecture build, integration development, data remediation, AI and tools integration (including Co-pilot and Claude rollout with training), bespoke build for residual gaps, and adoption support. Sized and costed in Stage 1 deliverable 3.

7.2Steady state with CrossVal as long-term partner

The RFP describes a steady state of improvements and optimisations after Stage 2, with the choice of continuing with the vendor or moving to internal teams.

CrossVal is built for the partner option in that choice. Post-Stage 2, the relationship continues as an embedded technology function: the stack is maintained, evolved, and operated with CrossVal as part of the Group's operating model rather than as an arm's-length supplier.

This is a different commercial shape from advisory firms that complete a project and exit, and a different model from arm's-length vendor relationships. It allows the Group to move into the post-Stage-2 phase without re-procuring or re-onboarding a partner who lacks the context built during Stage 1 and Stage 2.

7.3The internal-team option

If the Stage 1 operating model recommendation points toward internal teams for steady state, Stage 2 includes the build-out of those teams as part of implementation: hiring plan, capability framework, knowledge transfer from CrossVal, and the transition timeline from CrossVal-led to internal-led operation.

The deliverable in section 3.8 lays out both options, plus the hybrid model, so the Group can decide on the basis of strategy rather than default.

7.4Why this matters for Stage 1

Stage 1 produces outputs that are useful to whichever partner the Group engages for Stage 2. The methodology is platform-neutral and the deliverables stand alone.

That said, the most economic and continuity-efficient Stage 2 is one delivered by the team that produced Stage 1, given the contextual knowledge built during discovery. The Stage 1 fee credit reflects this directly.

08Team and credentials

8.1About CrossVal

CrossVal is a technology partner that embeds with professional services and financial services firms in the region across architecture, build, and ongoing operation. The firm is built on a specific view: the gap between strategy and operating reality in this market is best closed by a single partner who designs the architecture, builds what needs to be built, and stays to operate it. That structural commitment is what differentiates CrossVal from project-based advisory firms.

The combination of partners, full-time team, and strategic advisors brings together private equity and finance experience, operating-side digital transformation in regional firms, AI product depth from Silicon Valley finance startups, and senior advisory pedigree from Big 4 consulting and global enterprise software.

8.2Engagement team

The engagement is led by the CrossVal core team. Capacity allocations against each Stage 1 workstream are confirmed at kickoff.

Ajinkya Tanpure. Came up through private equity at ADCP, working at the intersection of finance and technology. Brings the commercial and operational lens for an engagement of this shape, including direct experience of the diligence and value-creation considerations that shape technology decisions in professional services firms.

Zohare Haider. Founded and exited multiple companies. Has led digital transformation programmes at telecommunications operators and operated as a technology investor. The end-to-end transformation experience, from strategy through delivery, is in environments comparable in complexity to the Group's.

Anirudh Madhavan. Worked as an early employee at AI and finance startups in San Francisco, including Spendflo and Livedocs. Has hands-on experience of building AI products in finance contexts. This informs the AI and tools assessment in Step 5 and the Stage 2 implementation approach.

Umna Qadri. Early employee at Alaan, the regional spend management platform, where she worked directly with finance leaders across the region on the operating-side mechanics of digital transformation. Her experience is most directly applicable to the role and function analysis in Step 6 and to engagement with Group finance leadership.

McKenzy Harrison. Has held turnaround and transformation roles at Daraz, the Alibaba Group, and Crescent Enterprises. Brings operational transformation experience in regional and cross-border contexts at scale.

8.3Strategic advisors

CrossVal's strategic advisors contribute to engagement methodology and review. They bring senior consulting and enterprise systems experience that complements the core team.

Saqr Ereiqat. Former Consulting Leader, Government and Public Sector, IBM. Brings senior consulting methodology, programme governance, and the structural rigour expected of large-scale advisory engagements.

Sohail Gondal. Partner at Accenture, formerly Senior Director at Oracle. Adds enterprise systems implementation experience, big-firm engagement methodology, and senior technology advisory perspective.

Raza Farooq. Business transformation expert. Spent 13 years at Ernst & Young, with subsequent experience at Accenture, work on the Neom programme in Saudi Arabia, and a current advisory role in organisational transformation at Mercer. His Big 4 transformation methodology shapes the role, function, and adoption analysis in Step 6, where organisational transformation expertise is most useful for the operating model and capability evolution view.

8.4Engagement leadership and selected experience

The Stage 1 engagement is senior-led across all workstreams. The combination of full-time team and advisor input brings partner-level seniority to the engagement, which is the basis for the senior-led delivery commitment in section 5.1.

Selected reference engagements and case studies are at casestudies.crossval.com.

09Next steps

This proposal covers Stage 1 only, in line with the Group's two-stage RFP.

We are happy to walk through it on a 30-minute call if useful, particularly to discuss the sequencing change on data quality (step 3) and any other points where alignment could be tightened.

On approval, kickoff begins within one week of contract signature.

APPENDIX AAssumption log

The Stage 1 engagement is delivered against the following assumptions. Material divergence from any of these is flagged as a scope risk and addressed through the engagement governance defined in section 5.

1. Quantios deployment scope. The Quantios deployment programme is sufficiently scoped at the start of Stage 1 for the integration architecture in step 2 to be mapped against it. Where Quantios scope decisions are still open, Stage 1 produces architecture against the most likely scope scenarios and flags scope-dependent recommendations explicitly.

2. Stakeholder access. The Group can make available the stakeholder access defined in section 5.2 within the engagement window. This includes partner and director level interviews across M/HQ, Rethink, and RAA, working sessions with the Group Systems team, and conversations with department heads for the role and function analysis.

3. Systems and data access. Read access to existing systems for capability and configuration review can be provided under appropriate confidentiality terms. Sample data extracts (timesheets, invoice history, workflow logs, data quality samples) can be shared where the analysis depends on them. Where access is restricted, Stage 1 falls back to structured leadership input as documented in section 5.5.

4. Existing role documentation. Job descriptions and current operating model documentation for the departments engaged in the role and function analysis are available, even if not fully current. Where documentation is missing, the analysis works from organisational chart, headcount file, and direct conversations with department heads.

5. Stage 2 commitment shape. Stage 2 scope is informed by Stage 1 output but is not pre-committed. Stage 1 output may recommend a Stage 2 of materially different shape, sequencing, or scale than current expectations. The Group retains full discretion on Stage 2 commissioning, partner selection, and the choice between CrossVal-led, internal-led, or hybrid delivery.

6. Q4 2026 deadline. The end-of-Q4-2026 implementation deadline is treated as the target. Where the gap analysis identifies more work than can be sensibly absorbed by that date, the roadmap recommends prioritised scope for completion within the window and documents deferred items for follow-on cycles.

7. Vendor calls. Permission can be obtained for selected vendor capability calls (Quantios, KYC360, Xero, and others as relevant) where these usefully inform the capability assessment in step 1.

APPENDIX BRisk register

The following risks are recognised as relevant to Stage 1 delivery. Each is paired with a mitigation approach. The risk register is reviewed during weekly steering check-ins and updated as the engagement progresses.