How privacy law actually constrains what banks can do with data

You open a checking account at a mid-size US bank. Buried in the account agreement, a checkbox is already ticked: "share transaction data with marketing partners." Eighteen months later, that same bank knows you bought baby furniture three times last month. Its marketing team wants to send you a personal loan offer for a nursery renovation. Legally, can they?

The answer is: it depends on exactly which data, which jurisdiction, which consent screen, and which downstream use. That "it depends" is the whole lesson. Let's trace the consent trail.

The consent trail: account opening to marketing email

Step 1: Account opening. The bank collects your name, address, Social Security Number (SSN) or national ID, income, and initial deposit. In the US, this is governed partly by the Gramm-Leach-Bliley Act (GLBA, 1999), which requires banks to give customers a privacy notice and, for certain third-party sharing, an opt-out (not opt-in) choice.

Step 2: Transactions accumulate. Every debit card swipe, direct deposit, and bill pay creates a data point. This is where things get interesting: transaction data reveals income patterns, health conditions (pharmacy purchases), religious affiliation (donations), and family status (childcare payments) without you ever declaring any of it.

Step 3: Marketing wants in. The team wants to build a "life event" model: detect a probable pregnancy or new child from spending patterns, then trigger a targeted loan offer. Technically, the transaction data already sits in the bank's warehouse. The question is whether *using it this way* is lawful.

This is the gap most non-technical bankers miss: possessing data and having a lawful basis to use it for a specific purpose are two different things.

Where GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → blocks it (if any customer is in the EU/UK)

The General Data Protection Regulation (GDPR), enforced across the EU/EEA (and mirrored by the UK GDPR post-Brexit), requires a specific lawful basis for each processing purpose, not just one blanket basis for "having a relationship with you."

Opening the account and processing payments falls under "contract necessity," no extra consent needed. But inferring a pregnancy or life event from spending and using it for marketing is a *new, incompatible purpose*. Under GDPR Article 6, this generally requires freely given, specific, informed consent, or at minimum, a legitimate interest assessment that a regulator would need to see documented.

Critically, GDPR also restricts special category data (Article 9): health, religion, sexual orientation, etc. If the inferred "pregnancy signal" counts as health-related data, it's presumptively banned from marketing use unless the customer gave explicit consent to that specific inferenceinferenceThe moment a trained AI model is put to work: it takes a new input and produces an answer, prediction or generated output.View full definition →. A pre-ticked box at account opening does not satisfy this. GDPR explicitly says consent must be an affirmative act, silence or pre-ticked boxes are invalid (ICO guidance on consent).

Penalty exposure is real: GDPR fines can reach 4% of global annual turnover. In 2024, Ireland's Data Protection Commission fined Meta 251 million euros for a related consent failure, unrelated to banking but the same legal mechanism.

Where CCPA/CPRA blocks it (US, California residents)

The California Consumer Privacy Act (CCPA), strengthened by the California Privacy Rights Act (CPRA, effective 2023), works differently: it's opt-out based for most data, but requires opt-in consent for "sensitive personal information," a category that includes precise geolocation and, arguably, health-inferred data.

Banks get a partial carve-out: data already regulated under GLBA is exempt from CCPA in many cases. But the exemption applies to GLBA-covered *financial* uses, not to secondary marketing inferences layered on top. A marketing team building a pregnancy-prediction model from transaction data is arguably stepping outside the GLBA exemption and back into CCPA territory, where California residents have the right to opt out of "sale or sharing" of personal information, including for cross-context behavioral advertising.

Other US states matter too: Virginia (VCDPA), Colorado (CPACPACost Per Acquisition: the total cost to generate one customer or conversion, computed by dividing total spend by the number of acquisitions.View full definition →), and others have similar sensitive-data consent rules as of 2026, though there is still no single federal privacy law in the US.

Where open banking rules block it

Open banking frameworks (the UK's Open Banking standard under the Competition and Markets Authority, and PSD2/the EU's revised Payment Services Directive; in the US, the CFPB's Section 1033 personal financial data rights rule finalized in 2024) govern data a bank receives *from* other institutions via APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → when a customer links accounts.

The core rule: data shared under open banking consent is purpose-limited by design. If a customer connects their savings account to a budgeting app, that data flowdata flowAn automated sequence of steps that moves data from source to destination: ingestion, transformation, validation, and loading, so it arrives clean and ready to use.View full definition → has a specific consent scope, typically 90 days in UK Open Banking, renewable. A bank cannot repurpose data obtained through an open banking data-sharing arrangement for unrelated internal marketing without a fresh, specific consent. The US CFPB rule (once fully phased in) similarly restricts data recipients from using consumer-authorized data for secondary purposes like targeted advertising without separate authorization (CFPB rule summary).

The practical governance layer: what banks actually build

Because rules differ by jurisdiction, data type, and purpose, banks can't rely on legal judgment alone at the point of each marketing campaign. They build data governance infrastructure:

• Purpose tagging: every data field is tagged with the lawful basis and permitted use cases at ingestion. Transaction data tagged "payments processing only" cannot flow into a marketing feature storefeature storeA centralised repository managing ML features, ensuring consistency between training and serving environments.View full definition → without a governance override.
• Consent management platforms (CMPs): centralized systems tracking what each customer consented to, when, and for what purpose, so marketing queries can filter populations before campaign launch.
• Data lineage tracking: documenting where a data field came from and every system it touched, required to answer regulator or customer "right to know" requests under GDPR Article 15 or CCPA.

A simplified purpose-tagging check might look like this in a data pipelinedata pipelineETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.View full definition →:

def can_use_for_marketing(record):
    if record['data_source'] == 'open_banking_api':
        return record['consent_scope'] == 'marketing' and not record['consent_expired']
    if record['contains_sensitive_inference']:
        return record['explicit_opt_in'] is True
    return record['gdpr_lawful_basis'] in ('consent', 'legitimate_interest_documented')

This is a toy example, but it reflects the real logic banks embed: the check happens before the campaign runs, not after a regulator asks.

The audits that actually catch violations

Governance policy is only as good as the audit that verifies it. Three checks a bank's data/compliance team runs regularly:

1. Consent-to-usage reconciliation: sample marketing campaign target lists and trace each customer's record back to a documented, non-expired consent matching that exact purpose. Mismatches are the single most common finding in EU Data Protection Authority (DPA) investigations.

1. Special category leakage scans: automated scans of feature stores and marketing datasets for fields correlated with health, religion, or other protected categories, even when not explicitly labeled as such (a "baby product merchant category code" flag is a proxy for a protected inference).

1. Cross-border transfer checks: if a US bank's marketing analytics vendor processes EU customer data, GDPR Chapter V requires a valid transfer mechanism (Standard Contractual Clauses, or reliance on adequacy decisions like the EU-US Data Privacy Framework, current as of 2023 and under ongoing legal challenge).

Key Takeaways

• Possession is not permission. A bank can legally hold transaction data for payments processing while being legally barred from using that same data for a marketing inference, because the lawful basis differs by *purpose*, not by dataset.
• GDPR requires purpose-specific, explicit consent for sensitive inferences (like health-adjacent life events); pre-ticked boxes or bundled consent at account opening do not qualify.
• CCPA/CPRA is opt-out by default but opt-in for sensitive personal information, and GLBA exemptions typically don't cover secondary marketing uses layered on financial data.
• Open banking consent is purpose- and time-scoped by design; data pulled via API for one purpose (like budgeting) cannot be silently repurposed for marketing.
• Governance is operational, not just legal: purpose tagging, consent management platforms, and data lineagedata lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition → tools turn abstract regulatory obligations into pipeline-level checks that run before a campaign launches, not after a fine arrives.