Customer Data Platform (CDP) for Banks and Financial Services

A customer data platform (CDP) connects customer records, consent and events for banks and financial firms. PrivyCDP runs in your datacenter or cloud account. Your team controls access and encryption keys. Use these guides to assess data flows, audit records and operating duties.

Who this is for

• Retail and corporate banks that need one view of a customer across retail, wealth and corporate lines, with consent and audit evidence the bank holds itself.
• Insurers in scope of the EU's Digital Operational Resilience Act (DORA), which covers insurance and reinsurance undertakings (with exemptions for some small ones) as well as credit institutions 1.
• Payments firms and card issuers that must keep cardholder data out of marketing and decisioning systems, and that are also DORA financial entities when they are payment or electronic money institutions 12.

The regulatory boundary at a glance

This table is a map, not an opinion on any institution's obligations. Each satellite page cites the primary texts.

The deployment pattern: on-premise core and a bank-owned VPC

The pattern PrivyCDP uses with banks keeps the customer data path inside infrastructure the bank owns. The components are an identity graph with deterministic stitching, a decision engine that runs inference in the perimeter, an append-only consent and audit ledger, and channel orchestration for email, SMS, push and branch. Keys are issued and rotated by the bank's own key management, and outbound traffic to advertising, marketing-technology and public analytics endpoints is blocked by default. PrivyCDP runs as licensed software; the bank operates the infrastructure 8.

Two arrangements are common. In the first, the platform is installed in a bank-owned VPC under the bank's identity and access controls. In the second, a hybrid, the core data plane (identity resolution, audit ledger, policy plane) runs on-premise and edge orchestration and inference run in a private cloud region 9. A sovereign or air-gapped option is listed for stricter requirements 9.

The anonymised Tier-1 European bank reference describes the first arrangement: installation on-premise in a bank-owned VPC, a unified profile graph across retail, wealth and corporate banking, AI-assisted segmentation inside the boundary, activation only to internal systems, no customer-data egress, and a fixed three-year cost model 10. Permissioned references and release-specific evidence can be requested during evaluation 8.

What to evaluate

1. Data ownership and exit. Can the bank export the identity graph, consent history and decision logs without vendor services?
2. Residency and keys. Where do data, backups, support access and inference sit, and who holds the keys?
3. Consent. Is consent a ledger with purpose, channel, timestamps and previous values?
4. Identity across lines of business. Are deterministic keys the default, and can a merge be reversed?
5. Audit evidence. Does the platform record profile reads and writes, segment changes, decisions and sends?
6. Model governance. Is every score used in a decision in a model inventory with an owner?
7. Operations. Who patches, monitors and restores? Infrastructure and DevOps are scoped separately from the licence.
8. Cost across the retention window. Is pricing independent of profile and event counts? See CDP pricing explained.
9. A bounded proof of concept. Use one workflow with synthetic records, covering consent withdrawal, duplicate handling and recovery after failed delivery 8.

A self-hosted platform is not right for every institution. A bank without a platform engineering team, or without a residency or key-control requirement for the data in scope, may be better served by a vendor-operated service with a contract that meets DORA Article 30 or its local equivalent.

Guides for banks

• Customer data platforms for banks: why projects fail, the regulatory map, which data may leave the perimeter, a neutral vendor view and a 20-item checklist.
• Customer 360 data model: entities, identity keys, survivorship, retention, PII tags and sample schemas.
• Real-time next best action inside the bank: decision pattern, latency budgets, model risk and the EU AI Act boundary.
• DORA and your marketing stack: the register of information, contract terms and exit plans.
• PCI DSS v4 and marketing data: keeping cardholder context out of the platform.
• Single customer view: definition and regulatory uses in banking.
• CDP pricing explained: MTU, events, credits and flat licences.
• Anonymised deployment cases and the deployment qualification form.

To test fit for your institution, complete the deployment qualification form; it records the workflow, boundary, scale and ownership questions in one place.