Banking CDP: build or buy

When the fork appears

Customer 360 initiative is mature. CMO wants faster. CTO wants ownership. Vendors (Salesforce, Tealium, Treasure Data, Bloomreach) pitch a 6-month pilot. Internal data engineering claims “9 months and ours”.

Banking-specific criteria

Data residency. PII in UZ — most vendors do not have a local region. Disqualifier for cloud CDP without on-prem option.

Regulatory requirements. CDP touches sensitive financial data — vendor must be compliant per cbu.uz expectations.

Cross-product complexity. Banking customer has 10-15 products across multiple systems. Identity resolution non-trivial — corporate hierarchies, joint accounts, UBO.

Consent granularity. cbu.uz biometric requirements + general data protection — granular per-purpose consent mandatory.

Integration depth with ABS. Tighter than typical CDP integration with marketing systems.

When buy

Mid-size bank with standard data complexity.

Limited data engineering team.

Need for speed (6-month launch).

Vendor offers on-prem or local cloud.

Use cases standard (marketing automation, basic personalisation).

When build

Large bank (multi-million customers).

Banking-specific identity requirements (UBO, hierarchies).

Strict data residency without vendor local region.

Strong existing data engineering team.

5+ year strategic horizon.

When hybrid

Buy for quick-win frontend (audience builder, segment activation), build for long-term backend (identity resolution, profile store).

Where decisions usually go wrong

Buy under “we have no team”. A year later no team, vendor raises prices.

Build under “everything unique”. 18 months later — generic CDP with retro design.

Vendor selection by feature list, not real banking job to be done.

Related

• /en/architecture/banking-cdp-architecture/ — CDP architecture
• /en/solutions/banking-customer-360-platform/ — customer 360
• /en/insights/banking-vendor-management/ — vendor management
• /en/decisions/banking-abs-modernization-timing/ — ABS decision