UK Bank — MarTech CDP Assessment

Section 01 · Executive Summary

Assessment Overview

mParticle represents the largest single investment in UK Bank's MarTech infrastructure. In its current configuration the platform operates primarily as an event collection, validation, and forwarding layer — a subset of its full licensed capability set. Several strategic features, including real-time audience syndication, predictive segmentation, and advanced identity resolution strategies, remain unconfigured. The platform's core event architecture is sound; however, an accumulating deficit in vendor responsiveness — particularly across compliance-critical areas — is creating measurable operational and regulatory exposure.

✦ Platform Strengths

Event collection and schema governance are well-implemented. Data Plans enforce schema contracts in real time. Dual Kinesis streams provide a clean source-of-truth path to the Data Lake. Consent-gated event flows are operational. MoEngage S2S is clean and accurate. IDSync identity resolution is active.

Capability Gaps

Paid media audiences are delivered via manual file export. No real-time syndication to GMP, Google Ads, Meta, Apple Search Ads, or Rakuten. All five audience capabilities — syndication, predictive, composable, suppression, and identity-strategy audiences — are unconfigured. IDSync uses an incomplete identifier set (no IDFV, no GAID).

Vendor Relationship Health

38 GOC feature requests since 2020. 58% remain in permanent backlog; 7 rejected outright. Rejected items include DSR forwarding, identity collision diagnostics, SSO role management, and SQS role-based auth — all compliance-critical for a regulated financial institution. Only 2 of 38 requests are on a committed roadmap.

Two Actions Independent of Platform Decision

1. DSR Supplementary Pipeline: The GDPR Right to Erasure gap (mParticle's DSR forwarding fails when a user profile contains only a Customer ID) should be addressed immediately via a parallel pipeline that resolves device identifiers from the Data Lake and submits them directly to AppsFlyer. This is a UK Bank engineering fix and does not require mParticle co-operation.

2. A2 Optimised S2S Fix (AppsFlyer Attribution): Decoupling AppsFlyer event forwarding from the Kit transformation layer — routing app events exclusively via mParticle S2S to AF — resolves the root cause of all attribution data divergence. This architectural change is platform-independent and can be deployed as part of the near-term optimisation work without a migration decision.

Section 02 · Configuration Review

Current State mParticle Configuration

A technical review of sources, destinations, audiences, identity resolution, and data governance as assessed in February 2026 — based on architecture diagrams, the GOC tracker, internal documentation, and stakeholder input from UK Bank's engineering and marketing teams.

29%

Use Cases Fully Working

46%

Use Cases Unmet

58%

GOC Requests Backlogged

7

Requests Rejected Outright

2.1 Sources & SDK Footprint

Source	Integration	Description	Status
iOS & Android App	mParticle Mobile SDK	App events, user attributes, sessions, push tokens. Primary collection surface. On-device Kit footprint: mParticle + AppsFlyer (nested) + Amplitude + MoEngage + Split.	Active
Website (chase.co.uk)	mParticle Web SDK	Web events, anonymous sessions, consent signals via in-house CMP (Consent Manager)	Active
AppsFlyer	Media Attribution Feed (Kit — inbound)	Attribution data, install signals, re-engagement events, SKAN conversion values. Data flows through the AF Kit before mParticle receives it — creating a dual event path and schema transformation that is the root cause of attribution discrepancy.	Active / Discrepancy
MoEngage	Base Comms Feed (S2S bidirectional)	Campaign engagement events, delivery receipts, OTP status. Clean bidirectional S2S path.	Active
Amplitude	Product Analytics & Fraud Feed	Product analytics events and fraud detection signals	Active
Data Lake (S2S)	Kinesis Stream / Batch	Backend enrichment and enriched profile data. Bidirectional path via Kinesis dual stream.	Active
Offline Sources	—	Call centre, branch, ATM, in-person interactions. Not connected to mParticle.	Not Connected

2.2 Destinations

Destination	Connection	Notes	Status
Data Lake	S2S via Dual Kinesis Stream (Monitoring + Analytics)	Source of truth. Zero-copy architecture maintained. Recommended primary data reference for all downstream analytics.	Active
Amplitude	mParticle SDK Kit → Amplitude SDK (device-mode)	Operational with minimal discrepancy. Amplitude cohort feed back to mParticle not configured.	Active
MoEngage	Server-to-Server (Data API)	Clean S2S path. No Kit transformation. No known issues.	Active
AppsFlyer	mParticle SDK Kit → AF Kit → AF Servers	Data divergence issue: Kit intercepts and transforms events before forwarding to AF servers — while simultaneously the same events stream S2S to the Data Lake with a different schema. This dual-path creates systematic attribution discrepancies. The A2 Optimised S2S architecture resolves this.	Active / Discrepancy
Split / Harness FME	mParticle SDK Kit → Split SDK	Experimentation and feature flags. No issues identified.	Active
Paid Media Platforms	Manual file export	GMP, Google Ads, Meta, Apple Search Ads, Rakuten — no native mParticle connections configured. Audiences delivered via manual file push with per-cycle security review.	Not Configured (Native)

2.3 Identity Resolution (IDSync)

Identifier	Source	Priority	Status
customer_id (hashed post-KYC)	Core banking	1 (highest)	Active
mP_id (Web SDK cookie)	mParticle Web SDK init	2	Active
af_id (AppsFlyer device ID)	On-device at app launch	2	Active
IDFV (iOS vendor identifier)	iOS OS — stable per app per device	—	Not Configured
GAID (Android Advertising ID)	Android OS	—	Not Configured

Identity Gap — Cross-Device Web-to-App

IDSync operates correctly for the core KYC flow (anonymous → CUID at account creation). A gap exists for web-to-app cross-session journeys: users who browse on web (mPID assigned) then install the app (af_id assigned) without completing KYC in a single session generate two unjoined profiles. Including IDFV and GAID in the IDSync priority list would materially improve cross-device profile completeness. The Profile Isolation strategy (one of mParticle's five configurable IDSync strategies) has not been deployed — it prevents pre-consent anonymous data being attributed to post-KYC known profiles, which is recommended for UK GDPR compliance in a banking context.

2.4 Audience Capabilities

Capability	Current State	Status
Native Paid Media Syndication	Not configured. All paid media audiences delivered via manual file export with per-cycle security review. No real-time connections to GMP, Google Ads, Meta, Apple Search Ads, or Rakuten.	Not Configured
Predictive Audiences (Cortex)	mParticle Cortex ML features not enabled. No propensity scoring, churn prediction, or LTV forecasting audiences active.	Not Configured
Composable Audiences (Warehouse-Native)	Zero-copy architecture in place. No composable audience queries against the Data Lake have been configured in mParticle.	Not Configured
Suppression Audiences	No automated suppression for recent converters, existing product holders, or consent-withdrawn users. Managed manually outside the platform.	Not Configured
IDSync Strategy — Audience Building	Profile Isolation (recommended for GDPR banking) not deployed. Identity strategy capabilities not leveraged for audience quality.	Not Configured

2.5 Data Governance

Governance Capability	Status
Data Plans (JSON schema per source)	Active
Data Catalog (central event registry)	Active
Live Stream Validation	Active
Enforcement Mode (block invalid events)	Partial
Compile-time Validation (Smartype)	Not Deployed
Infrastructure-as-Code (Terraform)	APIs Available — No Terraform Provider
Public API (persistent token auth)	Client ID/Secret (~8hr tokens, not persistent)

Active Transformation Rule	Applied To
PII SHA-256 hash on forward	Data Lake, MoEngage, Amplitude
Consent filter (block without marketing consent)	All downstream platforms
Ecommerce event data minimisation	Amplitude, Data Lake
Event deduplication (source_message_id)	All destinations
Bot / test traffic exclusion	All destinations

Section 03 · Vendor Performance

Reliability, Observability & Vendor Responsiveness

Evaluation across four dimensions — reliability, stability, observability, and vendor responsiveness — based on the internal GOC feature request tracker (38 requests submitted 2020–2025), incident records, and direct feedback from UK Bank's engineering and data teams.

38

Total GOC Requests (2020–2025)

58%

In Permanent Backlog

18%

Rejected Outright

5%

On Active Roadmap (2 of 38)

GOC Status Distribution

Backlog (no committed timeline)

58% · 22

Rejected outright

18% · 7

Ready for triage (unprioritised)

8% · 3

On committed roadmap

5% · 2

Untracked / informal

11% · 4

Vendor Responsiveness — Summary

Of 38 requests since 2020, seven have been rejected outright — including DSR forwarding, identity collision diagnostics, SSO role management, and SQS role-based authentication. These are explicit vendor refusals, not deprioritised items pending capacity. Five requests have remained in backlog for four to five years with no committed timelines. Only two of 38 requests have reached roadmap status. Engineering and marketing teams report declining confidence in the platform's ability to address compliance and operational requirements through the standard GOC process.

Key Findings by Theme

Gap	GOC Reference	Summary	Impact Classification
Invisible Event Name Limit	`GOC-0005226` Backlog Oct 2023	Undisclosed ceiling per workspace. When breached, new events silently disappear from the UI. No alert, no notification. UK Bank cannot raise or monitor the limit without vendor co-operation.	Silent Data Loss Risk
Egress Throttle	`GOC-0005975` Rejected	No self-service rate limiting on outbound destination traffic. Rejected; mParticle suggested a custom Lambda proxy at UK Bank's engineering cost and ongoing maintenance.	Downstream Overload Risk
Batch Buffering	`GOC-0000190` Sep 2020 (5 years)	Cannot consolidate small batches before forwarding to destinations. Increases API call volume and rate-limit exposure at scale.	Cost & Efficiency
Infrastructure-as-Code	Untracked ~4 years	Platform API, Data Planning API, Warehouse Sync API, Custom Access Roles API and CLI all available for automation and CI/CD workflows. No official Terraform provider — a gap identified in the current deployment. Config snapshots via API scripts are a supported but manual workaround. Material gap for GitOps-based change governance in a regulated environment.	Partial — No Terraform
Public API / Config Automation	`GOC-0006198` Jan 2025	Client ID + Client Secret credential management via mParticle dashboard. Bearer tokens (~8hr expiry, server-cached). API scope and permissions are editable per credential set. Tokens expire and cannot be revoked mid-session, only deactivated — they expire and cannot be revoked mid-session, only deactivated. Supports Platform API, Data Planning API, Warehouse Sync API for programmatic configuration.	Partial — Short-lived Tokens
Identity Collision Diagnostics	`GOC-0005670` Rejected	Following an incident where distinct users merged to the same MPID, UK Bank requested a search API. Rejected. No tooling to detect or remediate identity collisions — creating both regulatory and marketing accuracy risk.	Regulatory Risk
Workspace RBAC	`GOC-0004812` Apr 2023	No read-only Production workspace role. Anyone viewing production data for debugging must be granted write access. In backlog for over two years.	Security Exposure
Raw Payload Debugging	`GOC-0006012` Oct 2024	User Activity View shows events only after identity resolution. No access to inbound raw payloads, transformation state, or outbound payloads. Every debugging session requires a support ticket — typically 24–48 hour resolution.	Operational Friction
System Alerts Observability	`GOC-0005846` Jun 2024	Alerts show absolute error counts only — no percentages, no trend lines. Date selections beyond 30-day retention appear identical to zero errors, creating false operational confidence.	Operational Blindness

Section 04 · Technical Debt & Remediation

Known Gaps, Compliance Risks & Remediation Playbook

All 13 identified gaps are product-level constraints — not deployment issues. UK Bank engineering could have the most optimally configured mParticle instance available and would still encounter every one of these limitations. 5 of 13 can be partially mitigated by UK Bank at significant cost; 8 of 13 require mParticle product changes with no viable workaround.

Critical Finding

The 7 rejected requests represent deliberate vendor decisions. DSR forwarding, SCIM, identity collision diagnostics, and SQS auth are compliance requirements for a regulated financial institution — not discretionary feature requests subject to standard roadmap prioritisation.

4.1 Compliance-Critical Rejected Requests

GOC ID	Request	Response	Workaround?	Impact
`GOC-0006298`	DSR CUID-only Forwarding — deletion fails silently when profile has no device ID	Rejected	Partial — Data Lake supplementary pipeline	Active GDPR Risk
`GOC-0005670`	Identity Collision Diagnostics — search API for merged MPIDs	Rejected	Partial — warehouse SQL monitoring	Incorrect marketing comms; financial promotions regulatory risk
`GOC-0001822`	SSO / SCIM User Provisioning — provision via UK Bank IdP	Rejected	No	Orphaned accounts; fails internal security audit
`GOC-0001823`	SQS Role-Based Auth — no shared API keys	Rejected	No	Fails JPMC Cybersecurity audit requirements
`GOC-0001813`	AF Identity Stitching at Install — CUID unavailable at first touch for 100% of new users	Rejected	No	Systematic attribution failure at highest-value conversion event
`GOC-0005975`	Egress Self-Throttle — outbound rate limiting per destination	Rejected	Yes — Lambda proxy at UK Bank cost	Downstream overload risk during traffic spikes

4.2 Remediation Playbook — All 13 Gaps

#	Gap	GOC Ref	UK Bank Fix?	Recommended Workaround	Priority
1	Invisible Event Name Limit	`GOC-0005226`	Detection only	Monitoring script via Event Service API; alert on threshold approach. Requires vendor to disclose actual limit.	High
2	Egress Throttle	`GOC-0005975`	Yes — Lambda proxy	API Gateway → Lambda per destination. 2–3 weeks per destination. Ongoing maintenance.	Medium
3	Batch Buffering	`GOC-0000190`	No	None viable. Requires mParticle product fix. In backlog 5 years.	Medium
4	Infrastructure-as-Code	Untracked	Partial	Config snapshot tool via Management API to Git. ~1 sprint. Reduces but does not eliminate governance gap.	High
5	Public API / Config Automation	`GOC-0006198`	No	None. Cookie-based auth blocks all programmatic config and 4-eyes workflows.	Critical
6	Identity Collision Diagnostics	`GOC-0005670`	Partial	SQL query on Data Lake identity tables detecting anomalous CUID counts per mPID. Remediation still requires vendor tooling.	High
7	Workspace RBAC	`GOC-0004812`	No	None. Separate Dev workspace provides partial mitigation only.	Medium
8	System Alerts / Observability	`GOC-0005846`	Partial	External CloudWatch dashboards monitoring outbound events. Cannot surface internal pipeline states.	Medium
9	Raw Payload Access	`GOC-0006012`	No	None. Internal pipeline inaccessible. Every debugging session requires a support ticket.	Medium
10	Selective Data Replay	`GOC-0005973`	Partial	Dead Letter Queue architecture (API Gateway → Lambda → SQS) per critical destination. Re-drive failed events without full timeframe replay.	Medium
11	Nested JSON Support	`GOC-0005976` Roadmap	Yes — flattening	Pre-ingestion flattening already deployed. Request committed delivery date from vendor.	Low
12	SCIM Provisioning	`GOC-0001822`	No	Confirmed: mParticle has NO SCIM provisioning on any plan (verified Jan 2026). SAML 2.0 SSO available (SP-initiated only, requires mParticle support team to configure). No IdP-initiated login. No automated user lifecycle management. Manual user creation required. Escalate as contractual compliance requirement — SCIM is a regulatory access control requirement for a UK-regulated financial institution.	High
13	DSR SLA & CUID Forwarding	`GOC-0006298` + `GOC-0006014`	Partial	Parallel pipeline: on DSR, query Data Lake for device IDs linked to CUID → submit directly to AF API. Target 7-day end-to-end SLA via this path.	Critical

Section 05 · Use Case Mapping

32 Use Cases — February 2026 Status

Assessment across five business domains. Status reflects current mParticle configuration as at February 2026. Marketing use cases are most materially affected — 57% cannot be fully delivered in the current state.

29%

Fully Working (9 of 32)

25%

Partially Working (8 of 32)

46%

Not Working (15 of 32)

57%

Marketing Use Cases Affected

Domain	Use Case	Status	Root Cause / Notes
Data Collection	Mobile app event collection (iOS & Android)	Working	mParticle SDK active; Data Plans schema-validated
	Web event collection (chase.co.uk)	Working	Web SDK active with consent gate via CMP
	S2S / backend event ingestion	Working	S2S Events API operational for backend enrichment
	Offline / call-centre data ingestion	Not Working	No offline source connected to mParticle; data held in Data Lake only
Identity & Profiles	Anonymous-to-known stitching (post-KYC)	Working	IDSync Profile Conversion strategy active; CUID assigned at KYC completion
	Cross-device identity (web + app)	Partial	Web mPID and mobile af_id not joined without IDFV/GAID in IDSync
	Pre-consent data isolation (Profile Isolation)	Not Configured	Profile Isolation strategy not deployed; pre-consent data may be attributed to post-KYC profiles
	Identity collision detection & remediation	Not Working	GOC-0005670 rejected; no diagnostic tooling; warehouse SQL is only mitigation
	Multi-brand / multi-country RBAC	Not Working	GOC-0004812 in backlog 2+ years; workspace-level RBAC not available
Marketing Activation	Real-time audience creation from events	Partial	Audience builder available; real-time syndication to paid media not configured
	Paid media syndication — GMP / Google Ads	Not Working	Not configured; manual file export used as substitute
	Paid media syndication — Meta	Not Working	Not configured; manual file export used as substitute
	Paid media syndication — Apple Search Ads	Not Working	Not configured; manual file export used as substitute
	Audience suppression (converters / opt-outs)	Not Working	No automated suppression; managed manually outside platform
	Predictive audience scoring (churn / LTV)	Not Working	Cortex not enabled; no ML-based audiences active
	MoEngage base comms personalisation	Working	Bidirectional S2S with MoEngage operational
Attribution & Analytics	Mobile attribution routing to AppsFlyer	Partial	Attribution functional but Kit transformation creates data divergence vs Data Lake
	SKAN conversion schema management	Partial	SKAN functional on-device via AF; Kit version lag may delay schema updates
	Cross-channel web-to-app attribution	Not Working	GOC-0001811 (AF web kit) in backlog; no web-to-app attribution path
	AppsFlyer data accuracy (no discrepancy)	Not Working	Known active issue; A2 Optimised S2S fix (Scenario 1) resolves this
	Product analytics forwarding to Amplitude	Working	Amplitude Kit operational; minimal discrepancy observed
Governance & Compliance	GDPR consent enforcement	Working	Consent gate via CMP → mParticle SDK operational across web and app
	Data Subject Request processing	Partial	DSR executes in mParticle; CUID-only forwarding to AppsFlyer fails silently; 14-day SLA vs 7-day legal requirement
	Right to Erasure forwarding to all destinations	Not Working	GOC-0006298 rejected; device-ID-only forwarding leaves CUID-only profiles undeleted
	Infrastructure config audit trail (IaC)	Not Working	Terraform not supported; all config is manual UI with no code-based audit trail
	4-eyes approval for config changes	Not Working	Blocked by cookie-based API auth; GOC-0006198 in backlog

Section 06 · Future State Architecture

Four Architecture Scenarios

Four architecture scenarios have been evaluated. Each is presented on its own merits with an objective assessment of capabilities, risks, and suitability for UK Bank's operating context. The D2 diagram represents the Optimised mParticle state. S1 is the current mParticle baseline. S2 is the an alternative CDP replacement scenario. S3 is the cloud-native custom AWS CDP. A Hybrid approach is also described as a near-term stabilisation path.

D2 · Optimised mParticle State — Summary

Position: Retain mParticle as the core CDP and resolve the AppsFlyer data divergence via the A2 Optimised S2S architectural change. Introduce a Deduplication Gate, Schema Validation layer, Observability stack, and Reverse ETL capability. Activate native paid media audience syndication. The result is a materially more capable, lower-risk mParticle deployment with no migration risk and no SDK replacement.

Migration risk: Minimal. All improvements are additive. Engineering changes are staged and can be deployed across quarters. Existing instrumentation, Data Plans, IDSync configuration, and destination connections are preserved.

D2 — Architecture Layer by Layer

Layer 1

Collection

mParticle iOS SDKmParticle Android SDKmParticle Web SDK S2S Events API (backend / offline) CMP consent gate — initialises before any SDK fires NEW: Offline S2S ingestion — call centre, ATM, branch

Key Change

AF Kit Decoupled

REMOVE: AF Kit event forwarding from mParticle SDK pipeline RETAIN: AF SDK on-device for af_id generation, SKAN, OneLink deep linking AF SDK initialises only on marketing consent (CMP-gated) NEW: All app events routed exclusively via mParticle → S2S → AppsFlyer (no Kit transformation) NEW: AF attribution data flows: AF Servers → Data Locker → Azure (bypasses mParticle entirely)

Layer 2

Dedup Gate

NEW: Deduplication gate upstream of all destination forwarding Uses source_message_id as deterministic dedup key Prevents duplicate events reaching Data Lake and ad platforms during SDK retry or replay Critical for MoEngage — prevents duplicate outbound communications

Layer 3

Schema Validation

Data Plans — schema contracts per source (existing, active) Data Catalog — central event registry (existing, active) NEW: Compile-time validation via Smartype — catch violations pre-deployment NEW: Enforcement mode — quarantine non-compliant events, never silently drop

Layer 4

Identity

IDSync — CUID (P1), mP_id (P2), af_id (P2) — existing and active NEW: Add IDFV (iOS) and GAID (Android) to IDSync priority list NEW: Deploy Profile Isolation strategy — prevent pre-consent anonymous data attributed to post-KYC profiles NEW: Explicit logout calls in mobile SDK — clean session transitions

Layer 5

S2S Destinations

Data Lake (Kinesis dual stream) — source of truth MoEngage S2S — base comms (existing) Amplitude (Kit) — product analytics (existing) Split / Harness FME (existing) NEW: AppsFlyer S2S destination (replaces Kit forwarding) NEW: GMP, Google Ads, Meta (CAPI), Apple Search Ads, Rakuten — native audience syndication

Layer 6

Observability

NEW: CloudWatch / Datadog dashboards — error percentages, trend lines, P95 latency NEW: Dead Letter Queue per critical destination — selective failed-event retry NEW: Event name count monitoring script — detect invisible limit breach Note: internal pipeline payload visibility remains a vendor-controlled constraint

Layer 7

Reverse ETL

NEW: Reverse ETL via Fivetran / Census — pull enriched Data Lake profiles into mParticle Enables: LTV scores, churn propensity, Experian enrichment as mParticle audience attributes Three options: Fivetran/Census (Option 1 — available), Hightouch (Option 2 — new), Lambda/AWS native (Option 3) Preserves zero-copy architecture — Data Lake remains authoritative source of truth

Layer 8

Ad Platforms

GMP · Google Ads · Meta · Apple Search Ads · Rakuten All receive validated, deduplicated, consent-gated clean events Integration latency notes: AF native (API-dependent); Amplitude — Google Ads gcid only; MoEngage — Google Ads 6–12h, Meta 1–2h; Data Lake — ETL connectors required

AF Hybrid SDK Architecture — Single Event Path

On-device (AF SDK retained for): af_id deterministic device identifier · SKAN Conversion Schema calculation and registration · OneLink deep linking · Consent-gated initialisation via CMP · Aggregated Advanced Privacy (AAP)

S2S path (replaces Kit forwarding): All app events → mParticle SDK → mParticle Rules Engine → mParticle S2S Destination → AppsFlyer S2S Events API. No Kit transformation. No dual path. No schema divergence. Attribution data: AF Servers → Data Locker → Azure (zero mParticle involvement).

Result: Single event path. Deterministic and probabilistic attribution fully retained. SKAN fully functional. Zero data discrepancy. Clean S2S signal reaching all destinations simultaneously.

D2 — Staged Implementation Roadmap

Phase	Timeframe	Workstreams	Classification
Phase 0 — Immediate	0–4 weeks	DSR supplementary pipeline; warehouse SQL identity collision monitoring; config snapshot tool to Git	Critical — Compliance
Phase 1 — Near Term	4–12 weeks	AF Kit decoupling + S2S destination; IDFV/GAID in IDSync; Profile Isolation strategy; AF Data Locker → Azure direct path	High — Data Accuracy
Phase 2 — Medium Term	3–6 months	Native paid media syndication (GMP, Google Ads, Meta CAPI); Dedup Gate; DLQ per destination; CloudWatch observability; Smartype compile-time validation	High — Activation & Ops
Phase 3 — Strategic	6–12 months	Reverse ETL (Fivetran/Census); composable audiences from Data Lake; LTV/churn scoring in mParticle; mParticle executive escalation on compliance GOC backlog	Medium — Value Expansion

S1 · Current mParticle — Baseline State

Position: The existing mParticle architecture as deployed. Represents the starting point for the D2 optimisation work. Core event collection and validation are functional. Attribution data divergence from the AF Kit nested architecture is the primary technical issue to resolve. Multiple audience, identity, and governance capabilities remain unconfigured.

S1 — Current Architecture Summary

Collection

SDK + Offline S2S

mParticle iOS/Android/Web SDKCMP consent gate Offline S2S: call centre, branch, ATM, payment side-ingested via mParticle Events API (S2S) or batch file upload to Data Lake 5 on-device SDKs: mParticle + AF (nested kit) + Amplitude + MoEngage + Split

Issue

Dual Event Path

AF Kit intercepts app events → transforms → forwards to AF Servers Same events simultaneously streamed S2S to Data Lake via Kinesis — different schema, different timing Root cause of all AF data divergence: Kit transformation creates systematic discrepancy between AF reporting and Data Lake analytics

Spine

mParticle S2S

Schema validation (Data Plans)Consent filter Identity resolution (IDSync — CUID, mP_id, af_id) S2S destinations: AF S2S API (untransformed by kit), Amplitude HTTP, MoEngage API, Kinesis stream

Destinations

Current Active

Data Lake (Kinesis)MoEngage (S2S) Amplitude (Kit)Split (Kit) AppsFlyer (Kit — discrepancy) Paid media: manual file export only (GMP, Google Ads, Meta, Apple Search Ads, Rakuten)

Key Constraint in Current State

The AF Kit nested architecture is both the largest technical risk (data divergence) and the most impactful fix available. Decoupling the Kit is a phased engineering change, not a migration — it can be completed without any disruption to other mParticle capabilities or existing SDK instrumentation. The D2 architecture represents the optimised state that results from applying this and the other Phase 1 changes.

S3 · Custom AWS CDP — Summary

Position: Decommission mParticle and build a bespoke, cloud-native CDP on AWS infrastructure. This scenario eliminates all commercial CDP vendor dependency — replacing the CDP layer with proprietary event ingestion, identity resolution, ML-based segmentation, and audience activation built entirely on AWS managed services.

Strategic fit: Appropriate where maximum data sovereignty, 10–11 year retention, unique regulatory architecture, or long-term cost at extreme scale justify the investment. The highest-capability ceiling of the four scenarios — and the highest implementation complexity and timeline. Latency notes: all lags in S3 are caused by SRNs (ad platform Systems of Record Networks) — not by the UK Bank technology platform.

Migration risk: Very High. 24–36 month minimum implementation. No commercial vendor SLA or support. All CDP capabilities (schema governance, identity resolution, GDPR tooling, SCIM, observability) must be engineered from scratch.

S3 — Architecture Layers

Collection

AWS Collector

AWS Collector on-device: consent-aware, Events → API Gateway CMP consent gate — nothing initialises without consent (Legit Interest UK) AF SDK on-device: Attribution ONLY — af_id, deep links, SKAN (identical to D2/S2) iOS · Android · Web (www) as collection surfaces

Core CDP

AWS Custom CDP

API Gateway — event stream ingestion with rate limiting and auth AWS Lambda — transform, consent filter, consent gate, S2S route, PII handling Amazon DynamoDB — identity graph, ID stitching, profile store Amazon Personalize — ML audiences, predictive LTV, lookalikes Amazon Kinesis — real-time event streaming to Data Lake AWS Step Functions — complex pipeline orchestration AWS Lake Formation — fine-grained data governance and access control

Storage

Data Lake — S2S

Amazon S3 — event lake, 10–11 year retention, versioning, cross-region replication AWS Glue — ETL pipelines, data cataloguing, DataBrew for data preparation Amazon Athena — ad-hoc SQL audience queries, federated query to external sources Amazon Redshift Serverless — fast repeated analytical queries

Compliance

Built to Spec

DSR processing built natively — no vendor SLA constraints, fully configurable to 7-day requirement AWS KMS encryption — customer-managed keys across all services IAM least-privilege policies — no third-party employee access to customer data AWS CloudTrail + CloudWatch — full audit trail for all config changes (IaC-equivalent via CDK/CloudFormation) GDPR consent enforcement, SCIM, and schema validation must be engineered from scratch

Destinations

All Clean Events

Data Lake, Amplitude, MoEngage, AppsFlyer — via S2S GMP · Google Ads · Meta · Apple Search Ads · Rakuten Enriched Data: Experian segments, lookalikes, ML propensity scores Integration latency: AF (native, API-dependent); Amplitude (Google Ads gcid only); MoEngage (Google Ads 6–12h, Meta 1–2h); Data Lake (ETL Lambda-direct ingest)

Trade-offs

Key Risks

No pre-built destination connectors — each ad platform integration custom-engineered No commercial vendor SLA — UK Bank owns all uptime, resilience, and incident response All CDP capabilities (schema enforcement, audience UI, GDPR tools) built from scratch 2–4 years to feature parity with commercial CDPs; significant sustained engineering resource required Maximum data sovereignty, no vendor lock-in, configurable to any regulatory requirement Most cost-efficient at very high scale over a multi-year horizon

Hybrid Approach — Near-Term Stabilisation

Position: Deploy the architectural fixes that are platform-independent immediately (A2 Optimised S2S and DSR supplementary pipeline), stabilise the current mParticle deployment, and run a structured an alternative CDP evaluation in parallel. Converge on a committed platform decision at the next mParticle contract renewal with full commercial and technical information.

When most appropriate: Where UK Bank needs to resolve the data accuracy and compliance issues now — without waiting for a migration decision — while preserving optionality for a vendor change if mParticle's renewal terms do not include binding resolution commitments for compliance-critical GOC items.

Hybrid — Four-Stage Path

Stage	Actions	Timeframe	Decision Gate
Stage 1 — Fix Now	Deploy AF Kit decoupling (A2 S2S). Build DSR supplementary pipeline. Implement IDSync IDFV/GAID additions. Deploy Profile Isolation strategy. These are all platform-independent improvements with no migration dependency.	0–10 weeks	None — proceed immediately
Stage 2 — Stabilise	Activate native paid media syndication. Deploy observability stack. Implement Dedup Gate. Build config snapshot tool. Conduct mParticle executive escalation with GOC evidence and binding renewal conditions.	2–6 months	mParticle executive meeting outcome
Stage 3 — Evaluate	Run structured an alternative CDP RFI/RFP. Conduct TCO modelling with current event volumes and MTU projections. Review JPMPI an alternative CDP implementation learnings. Assess data residency and BYOK equivalence for UK regulatory requirements.	3–6 months	Full commercial and technical an alternative CDP assessment
Stage 4 — Decide	At contract renewal: (A) Renew mParticle with contractually binding compliance commitments (D2 path), or (B) initiate an alternative CDP migration programme with full business case and phased timeline.	6–12 months	Contractual renewal milestone

Section 07 · Engagement Scope

Scope Changes vs Original Brief

The assessment scope was adjusted from the original brief to reflect the complexity of materials uncovered during the discovery phase and to align with UK Bank's immediate decision priorities.

Scope Additions

Comparative Analysis: 24-dimension mParticle assessment comparison (originally 12 dimensions)
Migration Feasibility: All four scenarios evaluated (D2, S1, S2, S3, Hybrid) with objective trade-off analysis
Risk Assessment: Full Remediation Playbook with Chase-can-fix vs vendor-must-fix classification across all 13 gaps
Future State Architecture: D2 Optimised as primary detailed architecture with staged implementation roadmap
AF Hybrid SDK Architecture: Detailed A2 Optimised S2S design with layer-by-layer implementation specification
Gap Analysis: GOC-sourced evidence base for all identified limitations — 38 requests, status, and recommended escalation strategy

Scope Exclusions

Resource & Investment Estimates: FTE counts, vendor licence costs, and implementation budgets excluded from this deliverable
Change Management & Training Plans: Workforce transition and platform training roadmaps not in scope
Phased Multi-Year Technology Roadmap: Long-term (3–5 year) MarTech evolution roadmap not included
Data Ingestion Volume Metrics: Event throughput benchmarks, monthly tracked user counts, and capacity projections excluded
Vendor Commercial Terms: Pricing details, contract values, and renewal terms not referenced in this document

Section 08 · Conclusion & Open Items

Findings Summary & Recommended Next Steps

UK Bank's mParticle deployment has a functioning core — event collection, schema validation, consent enforcement, and Data Lake integration are all operational. The platform's current limitations fall into three categories: configuration gaps (things not yet activated), product constraints (vendor limitations irrespective of configuration), and vendor relationship health (the accumulating GOC backlog). Each category has a different resolution path.

Category 1 — Configuration Gaps

Paid media audience syndication, Reverse ETL, Profile Isolation strategy, IDFV/GAID in IDSync, Dedup Gate, and Smartype validation are all available within the current mParticle licence. These do not require any vendor engagement. They require UK Bank engineering resource. The D2 roadmap stages these across four phases.

Category 2 — Product Constraints

IaC support, persistent API token auth, raw payload debugging, and batch buffering are mParticle product limitations — present regardless of how the platform is configured. an alternative CDP provides all four natively. These gaps drive the GOC score gap and inform the platform comparison.

Category 3 — Vendor Relationship

7 rejected requests include DSR forwarding, SCIM, and identity collision diagnostics — all compliance requirements for a regulated financial institution. The recommended path is an executive escalation with binding renewal conditions framed around GOC-sourced evidence, not advocacy language.

Recommended Next Steps

Priority	Action	Owner	Timeframe
Critical	Deploy DSR supplementary pipeline — query Data Lake for device IDs on every CUID-only deletion request; submit directly to AF API. Resolves active GDPR exposure without vendor co-operation.	UK Bank Engineering	0–4 weeks
Critical	Decouple AF Kit — route all app events via mParticle S2S to AppsFlyer. Resolves all attribution data divergence. AF SDK retained on-device for SKAN and af_id only.	UK Bank Engineering + mParticle	4–10 weeks
High	Add IDFV and GAID to IDSync priority list. Deploy Profile Isolation strategy. Materially improves cross-device identity resolution and GDPR pre-consent isolation.	UK Bank Engineering	4–8 weeks
High	Schedule mParticle executive escalation. Present GOC tracker evidence. Request binding contractual commitments on DSR SLA (7-day), SCIM, and identity diagnostics as renewal conditions.	UK Bank ·	Before contract renewal
Medium	Activate native paid media audience syndication (GMP, Google Ads, Meta CAPI, Apple Search Ads, Rakuten) within mParticle. Eliminates manual file export dependency.	UK Bank Marketing + Engineering	3–5 months
Medium	Run structured an alternative CDP RFI/RFP in parallel with D2 implementation. TCO model against actual event volumes and MTU profile. Review JPMPI learnings. Decide at renewal.	UK Bank Technology +	3–9 months
Ongoing	Implement observability stack (CloudWatch/Datadog). Deploy config snapshot tool to Git. Implement Dedup Gate. Build warehouse SQL identity collision monitoring.	UK Bank Engineering	Phase 2 (3–6 months)

Overall Position

The case for the D2 Optimised path rests on two premises: the most impactful fixes (A2 S2S and DSR pipeline) are available now without any migration, and the vendor relationship can be tested through a structured executive escalation before a replacement decision is made. The case for evaluating an alternative CDP rests on a different premise: 11 of 16 GOC gaps and the majority of enterprise governance requirements are natively available in an alternative CDP today, and migration risk — while real — is a one-time cost that may be justified if the mParticle renewal does not include binding compliance commitments.

Both paths are rational. The recommended sequence is to fix what is fixable immediately, test the vendor relationship at executive level with specific binding conditions, and converge on a committed platform decision at the renewal milestone — with full commercial and technical information available.

Section 07 · Architecture Diagrams

Four Scenarios — Visual Architecture

Clean architecture diagrams for all four evaluated scenarios, mapped directly from the source architecture documents. D2 is the optimised future state for mParticle. S1 is the current mParticle baseline. S2 is the an alternative CDP replacement architecture. S3 is the cloud-native custom CDP built on AWS.

D2 · Optimised mParticle — Architecture Overview

Optimises the existing mParticle deployment. Key architectural change: decouples the AppsFlyer Kit from the mParticle SDK event pipeline, routing all app events via S2S to eliminate the dual event path and attribution data divergence. Adds Deduplication Gate, Schema enforcement (Smartype), Observability stack, Reverse ETL, and native paid media syndication. Zero migration risk — all changes are additive to the existing configuration.

🏦 UK BANK — Source of All Interactions

↓

① Interactions — Collection Surfaces

Digital (iOS)

App events
User attributes
Sessions
Push tokens

Digital (Android)

App events
GAID (add to IDSync)
Sessions & lifecycle

Web (chase.co.uk)

Web SDK events
Anonymous sessions
Consent signals

Offline ★ New

Call centre
Branch transactions
ATM interactions
In-person side-ingested via Events API / batch file upload

↓

② On-Device — Post Consent Only

mParticle SDK — Single Collection Point

Collects all events, identity signals & consent state
Generates cross_device_message_id for all events
appsflyer_id captured and forwarded to IDSync
IDFV (iOS) + GAID (Android) added to IDSync ★

AppsFlyer SDK — MUST BE ON DEVICE

Attribution ONLY — not event forwarding
Generates af_id (deterministic device identifier)
SKAN conversion schema + registration
Deeplinks + OneLink
Kit event forwarding REMOVED
No data sent back through mParticle via Kit

⚠ Root Cause of Attribution Discrepancy: When AF data routes through mParticle AF Kit, events get dropped and fields are lost — this is the root cause of the divergence between AppsFlyer and mParticle reporting. In D2, AF triggers AF S2S only. Attribution data flows directly to the Data Lake via native connector, bypassing Kit entirely.

↓

③ S2S Input Sources

UK Bank → mParticle

AF S2S API (untransformed by kit)
Amplitude HTTP API via Kinesis Stream
mParticle S2S Events API / events

↓

④ mParticle Optimised S2S Spine — Enterprise Data Backbone & Governance Layer

★ Deduplication Gate

Source-level: de-duplication across SDK → mP SDK Reply = single event
Per-output: client_dedup_id avoids on all consumers
Cost: ~£1K/mo server on in EU-AWS
Event dedup key: source_message_id

Failed Validation

Schema mismatch → quarantined
Never forwarded to output
Never forwarded to downstream
No overlapping events are dropped silently

Data Master — Schema Validation & Consent

Data Plans: event types, required fields, allowed values ★
Smartype compile-time schema validation ★ New
Enforcement mode — blocks invalid, never silently drops ★
Data Catalog — central registry of all data points

Identity Resolution

Single collection point: Events + Identity
IDSync: web ID, app ID, CUID, af_id
+ IDFV (iOS) ★ New
+ GAID (Android) ★ New
Profile Isolation strategy deployed ★

S2S Destinations

AF S2S API (untransformed by Kit)
Amplitude HTTP
moEngage API
Kinesis Stream (Data Lake)
Dedup Gate applied before each ★

Audience Sync

mParticle → moEngage
mParticle → GMP ★
mParticle → Google Ads ★
mParticle → Meta CAPI ★
mParticle → Apple Search Ads ★
mParticle → Rakuten ★
Suppression lists active

Single Event Path: Consent ✓ → mP SDK init → mP Servers → S2S to ALL downstream · No consent = no SDK init = no events captured = no data flows anywhere · AF attribution S2S only · Amplitude Kit: REMOVED · moEngage Kit: REMOVED

↓

⑤ Observability

★ Live Stream + Schema KPIs

Real-time schema validation dashboard
CloudWatch / Datadog error % + trend lines

★ Data Plan Violations

Alert on schema KPI thresholds
Event name count monitoring

★ DLQ per Destination

Dead Letter Queue: failed event retry
No full timeframe replay required

↓

Vendor Platforms — All Receive Validated, Deduplicated, Consent-Gated Clean Events

Azure Data Lake

moEngage

AppsFlyer

Amplitude

Split / Harness

↓

⑥A — Reverse ETL & Postback Loop

DATA LAKE

Enriched Data
S2S
LiveTran

Use Cases:

LTV / Propensity
Enriched
Historical Backfill
Sales Reconciled

Fivetran (Census) — Option 1

AF (Source only, not destination)
Amplitude (Native)
moEngage (Native)
AWS S3/GLUE (Native)

Hightouch — Option 2 New

AF (Source & Destination)
Amplitude (Native)
moEngage (Native)
AWS S3/GLUE (Native)

Lambda AWS — Option 3

AF (S2S API)
Amplitude (HTTP API)
moEngage (Data API)

⑥B — Third-Party Audience Data (3PA)

Experian

Mosaic segments, Employment
Demographic, residential
Property for deep inclusion

Partnerships

Retail partnerships, co-brand card data
Account data sharing, aggregators
Open Banking, Location intelligence
Data Clean Room collaboration

Data Clean Room

Privacy-first data collaboration
Data providers (e.g. GMC Meta) for audience segmentation
Segmentation: location, demographics, data
Provides Data Clean Room to help keep all media attribution in one ecosystem

Activation Paths: Option 1 — 3PA enriched profiles in Data Lake + Livetran syncs segments to mParticle Audiences → mParticle syndication → CustomMatch lists to Google Ads, Meta, GMP + events push data to Amplitude, moEngage, Rakuten · Option 2 (Recommended) — Composable Audiences can also query the warehouse directly (zero-copy) for real-time segment refresh via built-in connectors bi-directional to Data Lake

↓

Ad Platforms (Postbacks) — All Lags Caused by SRNs, Not by Technology Platforms

GMP

Google Ads

Original Architecture Reference Diagrams

The four original architecture diagrams as provided in the source documents. These are the reference inputs from which the interactive architecture diagrams above were constructed. Use the tabs to switch between scenarios.

D2 · Optimised mParticle — JPMC_D2 Source

Optimise mParticle: reduces SDK bloat & data discrepancy, improves data governance. Enterprise Data Backbone with Deduplication, Schema Validation & Observability.

S1 · Scenario 1 — JPMC_S1 Source

Optimise mParticle and reduce SDK bloat. Current baseline architecture with mParticle as CDP spine, AF Kit on-device, and S2S destinations to Amplitude, moEngage, AF, and Data Lake.

S3 · Scenario 3 — JPMC_S3 Source

Custom CDP on AWS. API Gateway → Lambda → DynamoDB → Personalize CDP spine. S3 / Glue / Athena data lake with direct Lambda ingest and 10–11 year retention.

CDP Platform EvaluationmParticle · Deep Dive

Assessment Overview

Current State mParticle Configuration

2.1 Sources & SDK Footprint

2.2 Destinations

2.3 Identity Resolution (IDSync)

2.4 Audience Capabilities

2.5 Data Governance

Reliability, Observability & Vendor Responsiveness

Key Findings by Theme

Known Gaps, Compliance Risks & Remediation Playbook

4.1 Compliance-Critical Rejected Requests

4.2 Remediation Playbook — All 13 Gaps

32 Use Cases — February 2026 Status

Four Architecture Scenarios

D2 — Architecture Layer by Layer

D2 — Staged Implementation Roadmap

S1 — Current Architecture Summary

S3 — Architecture Layers

Hybrid — Four-Stage Path

Scope Changes vs Original Brief

Scope Additions

Scope Exclusions

Findings Summary & Recommended Next Steps

Recommended Next Steps

Four Scenarios — Visual Architecture

Original Architecture Reference Diagrams

CDP Platform Evaluation
mParticle · Deep Dive