How to Implement Open Banking Data in Marketing

An open-banking marketing implementation is not a data-acquisition project. It is a governed service change in which a defined customer problem, a regulated data-access journey, a security architecture and a measurable business process must work together.

This guide is UK-focused and reflects the position checked on 28 July 2026. It is intended for marketing and CRM teams working with product, technology, architecture, privacy, risk, compliance, operations and regulated open-banking providers. It is not legal advice, and the UK regulatory details should not be copied into another jurisdiction without local review.

Before using this framework, design the customer value exchange. A technically sound implementation should not proceed when the customer benefit is weak, the same result can be achieved with less data, or the organisation cannot explain what happens when a customer declines.

A disclosure before the framework. I am the founder of Herm, which is built on purchase data rather than behavioural data, so I have a commercial interest in arguments about which customer data is worth collecting at all. Where I describe results below, they come from client work at the martech vendor where I ran accounts across Europe and the UK. They are anonymised, they were never designed as published research, and they should be read as personal observation. Anything carrying a reference number is a primary source you can open for yourself.

Start with a defined use case

“Use open-banking data for better personalisation” is not a use case. It does not identify the customer problem, the decision being improved, the minimum information required or the consequence of an incorrect result.

A viable use-case statement should specify:

• the customer task or problem;
• the customer population and exclusions;
• the service outcome;
• the organisational decision or process that changes;
• the minimum data input;
• whether access is one-off or ongoing;
• the regulated role required;
• the lawful and ethical basis for each downstream use;
• the measurement design;
• the conditions under which the programme will stop.

Example:

For customers who ask us to verify regular income, retrieve the minimum account information through an authorised AISP, derive a dated verification result, return that result to the case-management system, and end access after the verification window. Do not place raw transactions in the campaign platform or reuse them for promotional targeting.

That is implementable. “Build richer segments” is not.

Determine whether open banking is necessary

Before procurement, compare the proposed route with alternatives such as customer declaration, manual entry, document upload, first-party service data, a one-off verification or an existing payment method.

For the regulatory foundations, the data actually available through open banking and the marketing applications it supports, begin with our guide to open banking for marketers.

The tell I learned to listen for sits in the first meeting. A team explains that it wants to improve the customer experience, you ask what is actually wrong with the current setup, and the room goes quiet. They can see something is not working in their growth and performance numbers, and they cannot name it. What usually follows is a budget signed for the most advanced-looking capability on the market, because that is what a serious digital team is supposed to have.

The second thing worth saying plainly is that a data layer has a ceiling built into it. I spent years watching clients underperform for reasons that sat entirely outside marketing: late deliveries, storage failures, wrong stock data feeding the systems downstream, pricing that was simply not competitive. We could collect enough data to prove exactly why the brand was losing, and we had no say whatsoever over the pricing or the operations causing it. Open banking will not move any of those either. If the charter cannot name the broken thing, the programme is buying a capability rather than solving a problem.

Open banking is justified only when it materially improves the customer task or the reliability of a necessary decision and the benefit cannot be achieved proportionately with less intrusive data. The data-protection assessment should document necessity, proportionality and less risky alternatives. UK ICO guidance expects a DPIA to explain data flows, lawful basis, risks, mitigations and alternatives where processing is likely to be high risk.^[3]

Do not use a connection as a proxy for customer quality, loyalty or willingness to receive marketing. Permission for an account-information or payment-initiation service does not automatically authorise broader analytics, profiling or direct marketing. Those activities need their own purpose, lawful-basis and PECR analysis.^[17]

A 14-phase implementation model

The phases below are sequential gates, not a checklist to complete retrospectively. Each gate has an accountable owner, a decision, required evidence, a deliverable, a principal risk and an exit criterion.

Phase 1: Define the customer and business problem

Owner: Product owner, with a named business decision owner.
Decision: Is there a specific customer problem and a corresponding organisational action?
Required evidence: Customer research, current-journey data, complaint or service evidence, baseline process performance and a description of the decision that will change.
Deliverable: Approved use-case charter with population, exclusions, outcome, assumptions and non-goals.
Principal risk: Starting with available data or a supplier demonstration rather than a real customer need.
Exit criterion: The steering group can state the customer benefit, the business decision and the non-open-banking alternative in one page.

The charter should explicitly exclude adjacent ambitions. If the first use case is income verification, it does not also authorise transaction-based campaign targeting, affordability scoring and product recommendations.

Phase 2: Establish legal, regulatory and ethical feasibility

Owner: Legal and compliance lead, supported by the data protection officer and regulated-services owner.
Decision: Can the proposed service and each downstream use lawfully and fairly operate in the target market?
Required evidence: Regulatory perimeter analysis, FCA Register checks, lawful-basis assessment, PECR analysis, Consumer Duty or other conduct assessment where applicable, DPIA screening and an ethical-risk review.
Deliverable: Feasibility memorandum, regulatory-role map, lawful-basis register and DPIA decision.
Principal risk: Treating open-banking explicit consent as a universal permission for data protection and marketing.
Exit criterion: Every processing purpose and regulated activity has an owner, legal basis and control; unresolved high risks block progression.

In the UK, AISPs and PISPs may access, use or store information only for the service explicitly requested by the customer and must stay within the designated accounts and transaction information covered by that consent.^[1] A marketing team therefore cannot add a secondary purpose merely because the data is technically present. UK data-protection law makes the same demand from a different direction: a purpose must be specified before collection, and a later purpose has to be compatible with it or supported on its own footing.^[5]

Phase 3: Map the minimum data required

Owner: Data product owner and privacy lead.
Decision: What is the smallest set of source fields, history, accounts, refreshes and derived outputs needed?
Required evidence: Field-level purpose map, data-quality assumptions, alternative-data assessment, retention need and sensitivity review.
Deliverable: Minimum-data specification and prohibited-data list.
Principal risk: Importing broad transaction feeds “for future use”.
Exit criterion: Every requested field and refresh has a documented purpose, consumer-facing explanation and downstream destination.

Apply minimisation at four levels:

1. Account: request only accounts relevant to the feature.
2. Field: request only data clusters needed for the computation.
3. Time: use the shortest history and access duration that works.
4. Output: send a derived result rather than raw transactions where possible.

ICO guidance frames this as a test of adequacy, relevance and necessity against a specified purpose, which means collecting speculatively against a future use case is the failure mode the principle exists to prevent.^[4]

For example, a CRM may need “verification completed on 18 July, valid until 18 October” rather than six months of salary and merchant transactions.

Phase 4: Identify regulated and technical partners

Owner: Procurement lead with compliance, architecture and service-operations participation.
Decision: Which party performs the regulated service, which parties provide technology, and which contractual model preserves accountability?
Required evidence: FCA Register status, Open Banking Directory status where relevant, permissions, insurance, financial standing, ownership, subcontractors, security assurance, service history and exit capability.
Deliverable: Partner model, due-diligence record, responsibility matrix and approved shortlist.
Principal risk: Assuming a technical supplier’s relationship with a regulated provider transfers regulatory permission to the brand.
Exit criterion: The precise regulated entity, customer-facing identity and contractual chain are verified; no material role is labelled merely “platform”.

A technical service provider can support an AISP or PISP, but the regulated activity and customer accountability must sit with the appropriately authorised or registered party. Check the live FCA Register and relevant directory records rather than relying on sales material.

Supplier evaluation should cover:

• regulatory permissions by service and jurisdiction;
• supported account providers and account types;
• conformance with the current UK Open Banking Standard;
• customer redirect, dashboard and error capabilities;
• data residency and international transfers;
• subcontractors and onward provision;
• certificate and key management;
• availability, rate limits and recovery objectives;
• incident notification and forensic support;
• data deletion and evidence of deletion;
• portability and exit assistance;
• audit rights and material-change notification;
• commercial dependence and concentration risk.

OBL’s current supplier-management guidance recommends a systematic, cross-functional approach beginning with an end-to-end objective, clear pre-contract requirements, service levels, risk allocation, in-life management and exit needs.^[10] Regulated firms should read that alongside the FCA’s position on outsourcing and operational resilience, which treats reliance on a third party as something that does not transfer the firm’s own accountability for the service.^[16]

Phase 5: Map end-to-end data flows and responsibilities

Owner: Enterprise architect and data protection officer.
Decision: Where does customer data, permission state and derived information move, and which party controls each processing activity?
Required evidence: Sequence diagrams, system inventory, API calls, storage locations, data recipients, transfer mechanisms, access paths and deletion events.
Deliverable: Version-controlled data-flow map, controller/processor assessment and records-of-processing update.
Principal risk: A diagram that ends at the integration platform and ignores CRM exports, analytics copies, logs, backups and support tools.
Exit criterion: Each flow has a purpose, owner, role, security boundary, retention rule and revocation behaviour.

Controller and processor labels must be determined by actual decisions, not contract headings. The ICO states that the organisation deciding what data is collected, why it is used, who receives it and how long it is retained is likely to be a controller; a processor acts on the controller’s instructions for that processing.^[2] The same supplier may be an independent controller for a regulated service and a processor for another technical activity. Map roles per processing operation.

The data-flow map should include:

• customer interface;
• regulated provider;
• account provider;
• directory, certificate and identity components;
• API gateway;
• token and consent store;
• raw-data landing zone, if one is genuinely needed;
• transformation and quality services;
• derived-feature store;
• CRM, case-management or analytics destination;
• operational logs and monitoring;
• support access;
• data warehouse and business-intelligence extracts;
• backup, archive and deletion path;
• third-country transfers and subprocessors.

Phase 6: Design customer permission and revocation

Owner: Customer-experience product owner with compliance and engineering.
Decision: Does the customer journey accurately represent the data flow, duration, parties and alternatives?
Required evidence: Journey maps, copy, account and permission screens, reconfirmation flow, dashboards, revocation events, failure states and accessibility tests.
Deliverable: Approved permission-lifecycle design and event specification.
Principal risk: Designing consent screens after the architecture and contracts have already fixed an overbroad scope.
Exit criterion: A customer can understand, decline, complete, review, revoke and reconnect without hidden secondary uses.

The detailed customer design belongs in the guide to open-banking consent, adoption and trust. The implementation team must translate it into system events:

• consent created;
• account added or removed;
• access token issued, refreshed, failed or revoked;
• data retrieval succeeded or failed;
• 90-day background-access reconfirmation due, completed or missed;
• customer revoked through the AISP;
• customer revoked through the account provider;
• regulated-provider or supplier access terminated;
• service purpose ended;
• retention or deletion event triggered;
• reconnection started and completed.

In the UK, an AISP must stop background access if the customer has not reconfirmed within the previous 90 days. This is separate from bank reauthentication, which may occur for proportionate and objective reasons after the initial strong customer authentication.^[1] Design separate states for consent, access, authentication and service eligibility rather than one generic “connected” flag.

Phase 7: Implement security and access controls

Owner: Security architect and engineering lead.
Decision: Does the design protect credentials, tokens, financial data and administrative functions across their lifecycle?
Required evidence: Threat model, security architecture, current-standard mapping, certificate lifecycle, secrets design, access-control model, logging plan, vulnerability testing and resilience plan.
Deliverable: Approved security design and security-test plan.
Principal risk: Treating OAuth as the entire security architecture or placing open-banking tokens in general marketing infrastructure.
Exit criterion: High and critical security findings are resolved; key, token, access and incident controls have named owners and tested procedures.

As of 28 July 2026, UK Open Banking Standard v4.0.1 is the current published UK standard. Its security profile adopts the final Financial-grade API 1.0 Advanced profile.^[7][8] OpenID FAPI 2.0 is final internationally, but that does not mean the current UK v4.0.1 implementation has switched to FAPI 2.0.^[9]

Security architecture should address:

• standards-conformant authorisation and API calls;
• mutual authentication, certificates and certificate expiry;
• signing and validation where required by the standard;
• token isolation, encryption and rotation;
• secrets management outside source code and campaign tools;
• least-privilege service and human access;
• separate production, test and analytics environments;
• prevention of sensitive values in logs and traces;
• API rate, replay, injection and enumeration threats;
• mobile and browser redirect integrity;
• privileged-access monitoring;
• data-loss prevention and controlled export;
• dependency, vulnerability and penetration testing;
• availability monitoring and graceful degradation;
• backup and restoration tests;
• supplier outage and certificate-expiry exercises.

Do not copy raw transactions into a customer data platform simply because it has encryption at rest. Security includes purpose restriction, access visibility and reducing the number of systems that can expose the information.

Phase 8: Enrich and validate data

Owner: Data engineering lead and data product owner.
Decision: Can the organisation produce a reliable, explainable output from incomplete and variable account data?
Required evidence: Data dictionary, quality profiling, transformation rules, confidence measures, exception handling and manually reviewed samples.
Deliverable: Versioned transformation pipeline, quality controls and provenance record.
Principal risk: Presenting probabilistic categorisation or merchant matching as fact.
Exit criterion: Quality thresholds, correction routes and unsupported cases are defined; the output can be traced to source, rule version and timestamp.

Transaction data needs careful interpretation. Pipelines should distinguish:

• booked, pending, reversed and refunded entries;
• transaction date, value date and retrieval time;
• merchant name, payment reference and counterparty;
• card, transfer, direct debit, standing order and cash events;
• duplicate records and re-presented items;
• internal transfers between a customer’s accounts;
• joint and delegated account contexts;
• currency and exchange effects;
• category confidence and rule version;
• stale or partial account coverage.

A category such as “income”, “rent” or “subscription” is usually a derived classification, not a bank-certified fact. Store the confidence, evidence window and exceptions. Let operational users see that distinction, and provide a correction or manual-review route where the result matters.

Avoid deriving sensitive traits from merchants or transaction descriptions unless the use is specifically necessary, lawful, reviewed and communicated. Data that suggests health, religion, politics, union membership or sexuality can create special-category and fairness concerns even when the raw source is a payment account.

Phase 9: Integrate only required outputs into CRM and analytics

Owner: CRM architect and data governance lead.
Decision: What minimum output must enter each downstream system to support the approved action?
Required evidence: Field mapping, identity-resolution rules, purpose and access matrix, consent-state propagation, deletion test and campaign eligibility logic.
Deliverable: Approved integration contract and downstream data dictionary.
Principal risk: Turning the CRM into a permanent replica of transaction history.
Exit criterion: Each destination receives only the fields it needs; revocation, objection, expiry and deletion propagate successfully in testing.

A safer pattern is to keep source financial data in a restricted service or analytical boundary and send only narrowly defined outputs downstream. Examples include:

• verification status, evidence date and expiry;
• customer-selected budget band;
• confirmed recurring-payment count;
• customer-requested alert state;
• service eligibility with reason code and review date;
• connection health and last successful refresh;
• permission status and next reconfirmation date.

Do not send free-text bank descriptions, full merchant histories or balances to campaign users unless the approved service genuinely requires them.

Identity resolution

One of the largest cosmetics groups I worked with never reconciled identity between its offline estate and its several websites. Every purchase through a new channel created a new user record, so the same person existed several times over and every count built on top of that was wrong. The category tracking had drifted so far that the file they sent us listing each customer’s most purchased category contained category names that meant nothing to anyone. They eventually paid a CRM vendor a great deal of money to sort it out. That was ordinary retail data, with ordinary consequences, sitting inside a 360-degree programme that had been presented internally as working.

Financial data warrants a much higher identity threshold than that. Prefer authenticated, deterministic linkage using a stable first-party identifier. Avoid attaching open-banking outputs through email similarity, household inference or other probabilistic matching. A false positive can expose one person’s financial circumstances to another profile.

Permission-aware eligibility

Campaign or service eligibility should evaluate:

• approved purpose;
• current permission and access state;
• account and data scope;
• freshness and quality;
• lawful basis and marketing preference where relevant;
• vulnerability or suppression guardrails;
• output expiry;
• channel restrictions;
• experiment assignment.

A connection status alone is not an eligibility rule.

For broader architecture choices outside open banking, see privacy-safe personalisation.

Phase 10: Define measurement and harm guardrails

Owner: Measurement lead with product, risk and customer-operations owners.
Decision: What evidence would justify scaling, changing or stopping the implementation?
Required evidence: Metric definitions, baselines, instrumentation, comparison design, expected decision thresholds and harm indicators.
Deliverable: Measurement plan and stop/go scorecard.
Principal risk: Claiming ROI from attributed activity without establishing incremental effect or ignoring harm because adoption grew.
Exit criterion: Every KPI has a definition, denominator, owner and decision; harm thresholds can override commercial targets.

A French beauty retailer I worked with sent its loyal segment a discount email thirty days after purchase. For five months the reporting was excellent: strong opens, strong clicks, strong conversions, and a campaign everyone in the room was pleased with. Then we held part of the segment back and compared. Opens were similar, clicks were actually lower, and the conversion difference was about two per cent. The programme had spent five months paying people who were going to buy anyway.

There is a related habit worth naming, because it is what allowed that to run unchallenged for five months. No single statistic is the misleading one. Reading any statistic on its own is what misleads. A conversion-rate uplift can look excellent while the average order value underneath it is negative, and the two numbers only mean anything together. Open-banking outputs make both errors easier rather than harder, because bank data carries an authority that makes people stop asking for a control group.

Use four metric families.

Customer outcome

• completion of the customer task;
• time and effort saved;
• accuracy or correction rate;
• ongoing use where the proposition is ongoing;
• alternative-route success.

Technical and data quality

• connection and retrieval success;
• latency and availability;
• stale-data rate;
• provider-specific failures;
• classification confidence and error;
• revocation and deletion propagation time.

Operational and governance

• support contacts and complaint rate;
• permission mismatches;
• access-policy violations;
• incidents and near misses;
• supplier service-level performance;
• reconfirmation and disconnection outcomes.

Business outcome

• the decision or process improvement named in the charter;
• incremental commercial effect where an appropriate experiment or comparison is feasible;
• delivery and operating cost;
• cost of manual fallback;
• avoided error or rework.

Do not use a customer’s connection as proof that a marketing message caused a sale. The broader methodology for baselines, attribution, experiments and decision ownership belongs in Herm.io’s marketing measurement framework. For post-cookie data instrumentation, see first-party-data measurement.

Phase 11: Pilot with a limited population

Owner: Programme manager and product owner.
Decision: Can the service be tested safely with a population small enough to control but large enough to expose real operating conditions?
Required evidence: Eligibility rules, exclusion criteria, provider coverage, support capacity, monitoring, rollback, experiment design and participant communications.
Deliverable: Pilot plan and approved launch population.
Principal risk: Calling a production launch a pilot while lacking rollback, limits or a learning agenda.
Exit criterion: Population, duration, traffic caps, provider scope, stop triggers and review date are approved.

A useful pilot narrows several dimensions:

• one customer problem;
• one or a small set of account types;
• a limited provider set if necessary;
• one destination system;
• a short list of derived outputs;
• a defined customer cohort;
• capped volume;
• staffed support hours;
• an explicit end date.

Do not exclude difficult providers, devices or accessibility modes forever. Use the first pilot to stabilise the service, then deliberately expand coverage tests before claiming general availability.

Phase 12: Test operations, support and incidents

Owner: Service owner, incident manager and customer-operations lead.
Decision: Can the organisation detect, explain and recover from failures without exposing customers or losing control of data?
Required evidence: Runbooks, support scripts, escalation paths, supplier contacts, incident classification, breach assessment, continuity exercise, complaint routing and reconciliation tests.
Deliverable: Operational readiness pack and completed simulation records.
Principal risk: Testing only the happy-path API call while support, revocation and supplier outage processes remain theoretical.
Exit criterion: End-to-end simulations pass for outage, certificate expiry, consent mismatch, incorrect output, revocation, data breach and supplier failure.

The test plan should include:

• model-bank and sandbox integration;
• conformance and security testing;
• first live occurrences with controlled volumes;
• bank app unavailable;
• redirect not returned;
• partial or stale data;
• 90-day reconfirmation missed;
• revocation at the AISP and account provider;
• deletion across primary, analytical and downstream stores;
• customer dispute of a derived result;
• mislinked identity;
• supplier breach or extended outage;
• expired certificate or secret;
• rollback to the alternative journey.

OBL’s current testing guidance recommends integration testing, ecosystem testing and first-occurrence validation, with testing repeated for changes and enhancements.^[11] Its business-continuity guidance distinguishes service continuity from technology recovery and recommends plans, responsibilities and regular testing.^[12]

A personal-data breach requires a documented risk assessment. Where UK reporting is required, the ICO expects notification without undue delay and, where feasible, within 72 hours of awareness. Contracts should make supplier notification fast enough for the controller to meet that obligation.^[15]

Phase 13: Review evidence

Owner: Independent review chair or steering committee not solely accountable for delivery.
Decision: Did the pilot solve the defined problem within quality, cost and harm limits?
Required evidence: Pre-agreed scorecard, segmented results, incident and complaint review, control exceptions, customer feedback, supplier performance and unresolved risks.
Deliverable: Evidence review with recommendation and conditions.
Principal risk: Reframing success criteria after launch or averaging away poor outcomes for a provider or vulnerable group.
Exit criterion: The committee records one of four decisions: scale, extend the pilot, redesign or stop.

Separate:

• observed facts from assumptions;
• attributed outcomes from incremental effects;
• connection success from customer value;
• overall averages from provider, device and cohort differences;
• temporary pilot workarounds from scalable controls.

A pilot that proves the service cannot be delivered proportionately is successful evidence, even when the decision is to stop.

Phase 14: Scale or stop

Owner: Executive sponsor and service owner.
Decision: Should the service expand, remain limited, be redesigned or be retired?
Required evidence: Phase-13 review, capacity and resilience assessment, financial model, control maturity, supplier readiness and decommission plan.
Deliverable: Scale plan or controlled closure plan.
Principal risk: Scaling the connection volume faster than support, revocation, monitoring and supplier capacity.
Exit criterion: Funding and accountability are approved for the chosen path, including decommissioning and deletion where the service stops.

Two habits are worth carrying into this decision. The first is that a result which won once will not keep winning. Users change, audiences change, and I have watched too many permanent winners quietly decay to trust a single validation. Either leave a smaller control group running against the live service, or re-run the comparison at something like six-month intervals.

The second is that a good deal of what you are scaling rests on decisions other people make. I watched an entire channel lose most of its commercial value because a platform vendor changed its policy, and no amount of internal effort reversed it. We could manage the decline, argue about it internally and eventually restructure the product around it, but we could not fix it. An open-banking service depends on regulatory rules, a scheme, a standard version and a set of participating account providers, none of which the implementing organisation controls. Build the review cadence on that assumption rather than on the hope that today’s conditions hold.

Scaling means more than increasing traffic. Reassess:

• new account providers and account types;
• changed regulatory or standard versions;
• new customer populations;
• new data fields or output destinations;
• new suppliers or subprocessors;
• model or categorisation changes;
• revised retention;
• expanded direct-marketing use;
• cVRP participation and use-case scope;
• cross-border rollout.

If the change includes commercial variable recurring payments, treat it as entry into a payment scheme rather than a feature toggle. The UKPI rulebook restricts cVRP to participating entities and in-scope use cases, requires customer-agreed mandate parameters with routes to view and revoke them, and covers personal current accounts unless an account provider has specifically opted in to further account types.^[18]

Each material change may require a new DPIA assessment, customer explanation, testing and approval. OBL’s data-management guidance frames the lifecycle from setup through consent management, revocation, complaints and off-boarding rather than treating go-live as the end.^[13]

Regulatory and data-protection roles

A typical implementation may involve:

• Customer or payment service user: selects accounts and authorises the requested service.
• Brand or service organisation: defines the customer proposition and often determines the purpose of downstream processing.
• AISP: provides the regulated account-information service.
• PISP: provides the regulated payment-initiation service.
• ASPSP: the customer’s bank or account provider.
• Technical service provider: supplies connectivity, hosting, data processing or customer-facing components without necessarily performing the regulated service itself.
• CRM, analytics and cloud suppliers: process derived or source data according to their actual role and contract.

Do not collapse regulated status and data-protection status into one label. An AISP may be the regulated service provider and an independent controller for part of the processing. A cloud or transformation supplier may be a processor. The brand may be a controller for deciding that a verification result enters its case system. Joint control is possible where purposes and essential means are jointly determined. Document the reasoning.

Contracts should cover, as applicable:

• service and processing scope;
• controller, joint-controller and processor responsibilities;
• customer notices and complaint ownership;
• permitted purpose and prohibition of secondary use;
• subprocessor approval and visibility;
• international transfers;
• security and audit evidence;
• incident notification;
• data-subject rights assistance;
• availability and recovery targets;
• data quality and correction;
• retention and secure deletion;
• regulatory change;
• exit, portability and deletion certification;
• liability and redress.

Where a supplier acts as a processor, UK data-protection law sets a minimum contractual content that the parties cannot simply negotiate away, covering subject matter, duration, nature and purpose, data types, obligations and rights.^[14] Treat that list as the floor rather than the specification.

API and identity integration

The identity design should keep four identities distinct:

1. the authenticated customer in the brand service;
2. the payment service user known to the regulated provider;
3. the account and account provider selected in the open-banking journey;
4. the CRM or case record receiving a derived output.

Document how those identities are linked, how the link is verified, what happens when accounts are joint or delegated, and how a mismatch is corrected. Never use bank credentials as a linking mechanism.

The integration contract should define:

• API and standard version;
• request and response schemas;
• permission and account scope;
• idempotency and replay handling;
• error taxonomy;
• timeouts, retries and circuit breakers;
• provider-specific exceptions;
• pagination and historical-window rules;
• webhook or polling behaviour;
• status and revocation events;
• data freshness;
• audit and correlation identifiers;
• deprecation and migration process.

Do not let provider-specific behaviour leak directly into CRM logic. Normalise status and quality signals in an integration layer while retaining the original provider code for diagnosis.

Purpose and access controls

Access should be authorised by purpose, not merely by job title. A marketer who can use a derived eligibility flag does not automatically need to see source transactions.

Build an access matrix that combines:

• user or service identity;
• approved purpose;
• data class;
• customer permission state;
• account scope;
• environment;
• time and expiry;
• action: read, transform, export, correct or delete.

Review privileged and bulk access separately. Alert on unusual queries, large exports, access outside support cases and repeated attempts to view suppressed fields. Record administrative changes to permission and retention rules.

Retention and deletion

UK data-protection law does not set one universal retention period for open-banking marketing data. The organisation must justify how long each category is needed, review it and delete or anonymise data that is no longer necessary.^[6]

Create a schedule by data object:

Data object	Typical purpose question	Retention trigger	Deletion or archive control
Consent and access record	What permission was given and when?	Regulatory, complaint and evidential need	Restricted evidence store with defined period
Access token or secret	Is it still needed for an active service?	Revocation, expiry, supplier termination or purpose end	Immediate invalidation and secure deletion
Raw account information	Is source detail required after transformation?	Successful output, correction window or case closure	Delete from landing and transient stores; verify replicas
Derived verification	How long can the result remain valid?	Result expiry, account closure or purpose end	Expire eligibility and remove downstream copies
Marketing eligibility	Does the purpose and lawful basis still apply?	Objection, consent change, campaign end or output expiry	Suppress immediately; delete under schedule
Operational logs	What is needed for security and service diagnosis?	Log-retention period	Redact sensitive payloads; immutable deletion policy
Backups	How will deleted data age out?	Backup cycle and legal hold	Document maximum residual period and restoration controls

Revocation of open-banking access does not automatically determine the lawful retention of every historical record, but it must stop future access and trigger the documented review. Do not promise immediate deletion of all records where legal or complaint evidence must be retained; explain the distinction plainly.

Operational support

Support needs enough information to diagnose the journey without unrestricted transaction access. Provide:

• connection and provider status;
• timestamps and correlation IDs;
• permission and reconfirmation state;
• standardised failure code;
• last successful refresh;
• safe retry and alternative route;
• escalation destination;
• complaint and data-rights route.

Do not ask customers to send bank credentials, authentication codes or complete statements through an insecure channel. Support scripts should identify which organisation handles authentication, payment disputes, data accuracy, service complaints and privacy requests.

Incident and complaint handling

Classify incidents across:

• availability and performance;
• security and personal-data breach;
• unauthorised or excessive access;
• incorrect identity linkage;
• incorrect transformation or decision;
• consent and revocation mismatch;
• payment error or unauthorised transaction;
• supplier failure;
• misleading customer communication;
• direct-marketing misuse.

For each class, define detection, severity, containment, customer communication, regulator or scheme notification, remediation and evidence preservation. Complaints should be analysed as control signals, not only closed as individual cases.

Implementation responsibility matrix

Responsibility	Accountable owner	Required contributors	Evidence at governance review
Customer problem and proposition	Product owner	CX, research, operations	Use-case charter and journey evidence
Regulated perimeter and permissions	Compliance lead	Legal, regulated provider	Permission checks and role map
Data protection and ethics	DPO or privacy lead	Legal, product, security	Lawful-basis assessment, DPIA and mitigations
Supplier selection	Procurement lead	Compliance, security, architecture, finance	Due-diligence file and contract controls
Architecture and data flows	Enterprise architect	Engineering, data, privacy, supplier	Diagrams, inventory and role mapping
Security	Security architect	Engineering, operations, supplier	Threat model, tests and remediation
Data quality and transformation	Data product owner	Engineering, analytics, operations	Dictionary, quality results and provenance
CRM and analytics integration	CRM architect	Marketing operations, privacy, data governance	Field map, access matrix and deletion test
Customer permission lifecycle	CX product owner	Compliance, engineering, support	Approved screens, events and dashboard tests
Measurement	Measurement lead	Product, finance, risk	Metric dictionary and decision scorecard
Operations and incidents	Service owner	Support, security, supplier, legal	Runbooks, simulations and contact tree
Scale or stop	Executive sponsor	Steering committee	Evidence review and signed decision

Implementation checklist

Use case and feasibility

• Customer problem, population, outcome and non-goals are defined.
• A lower-data alternative has been assessed.
• The regulated activity and provider are verified.
• Every data use has a lawful basis and purpose.
• Direct-marketing use has a separate UK GDPR and PECR assessment.
• DPIA screening is complete and high risks are resolved or escalated.

Data and architecture

• Minimum accounts, fields, history and refresh are approved.
• Data flows include logs, exports, backups and subprocessors.
• Controller and processor roles are mapped per activity.
• Raw and derived data are distinguished.
• Provenance, confidence and correction are designed.
• CRM receives only necessary outputs.
• Identity linkage is deterministic and testable.

Security and resilience

• Current UK standard and security-profile versions are recorded.
• Certificates, keys, tokens and secrets have lifecycle owners.
• Access is purpose-based and least-privilege.
• Sensitive values are excluded from logs.
• Conformance, vulnerability and penetration tests are complete.
• Outage, certificate-expiry, revocation and restoration exercises pass.
• Supplier incident and exit procedures are tested.

Customer and operations

• Permission screens match the implemented data flow.
• Decline and alternative journeys work.
• Failure and recovery messages are actionable.
• Consent, access, authentication and eligibility are separate states.
• Dashboards, 90-day reconfirmation, revocation and reconnection are tested.
• Support can diagnose without seeing unnecessary transactions.
• Complaint, correction and privacy-rights routes are clear.

Measurement and governance

• Baselines and denominators are documented.
• Customer, technical, operational, business and harm metrics have owners.
• Stop thresholds can override commercial targets.
• Pilot scope, duration, caps and rollback are approved.
• Evidence review is independent of day-to-day delivery.
• Scale, redesign and decommission paths are funded.

Frequently Asked Questions

Conclusion

A credible open-banking marketing implementation narrows the use case before it widens the data flow. It verifies the regulated and data-protection roles, minimises source data, isolates sensitive infrastructure, integrates only necessary outputs, propagates permission changes and measures customer value alongside technical quality and harm.

The governing question at every phase is not “Can the data reach the CRM?” It is “Should this specific output reach this system for this purpose, under this permission, for this period, with a tested route to stop?”

References

1. Financial Conduct Authority. Payment Services and Electronic Money – Our Approach – March 2026 (version 7). Finalised guidance, published 31 March 2026. Official identifier: Finalised Guidance, version 7; PSRs 2017 and SCA-RTS guidance. Source type: regulator guidance. Interest disclosure: the FCA regulates UK payment services and explains its supervisory interpretation.
2. Information Commissioner’s Office. How do you determine whether you are a controller or processor? Regulatory guidance, undated web guidance accessed 28 July 2026; page notes review following the Data (Use and Access) Act 2025. Official identifier: UK GDPR controllers and processors guidance. Source type: regulator guidance. Interest disclosure: the ICO regulates UK information rights and data protection.
3. Information Commissioner’s Office. Data protection impact assessments. Regulatory guidance, undated web guidance accessed 28 July 2026; page notes ongoing updates following the Data (Use and Access) Act 2025. Official identifier: UK GDPR accountability guidance. Source type: regulator guidance. Interest disclosure: the ICO regulates UK information rights and data protection.
4. Information Commissioner’s Office. Data minimisation. Regulatory guidance, updated for the Data (Use and Access) Act 2025 and accessed 28 July 2026. Official identifier: UK GDPR data-protection principles guidance. Source type: regulator guidance. Interest disclosure: the ICO regulates UK information rights and data protection.
5. Information Commissioner’s Office. Purpose limitation. Regulatory guidance, updated 23 March 2026. Official identifier: UK GDPR data-protection principles guidance. Source type: regulator guidance. Interest disclosure: the ICO regulates UK information rights and data protection.
6. Information Commissioner’s Office. Storage limitation. Regulatory guidance, accessed 28 July 2026. Official identifier: UK GDPR data-protection principles guidance. Source type: regulator guidance. Interest disclosure: the ICO regulates UK information rights and data protection.
7. Open Banking Limited. OBL publishes Open Banking Standard v4.0.1. Official release, published 1 April 2026. Official identifier: UK Open Banking Standard v4.0.1. Source type: official standard-setter release. Interest disclosure: OBL develops and maintains the UK standard and has an institutional interest in its adoption.
8. Open Banking Limited. Security Profiles. Technical standard page, current v4.0.1 accessed 28 July 2026. Official identifier: UK Open Banking Standard v4 Security Profile. Source type: official technical standard. Interest disclosure: OBL develops and maintains the UK standard.
9. Dave Fett, Daniel Tonge and Joseph Heenan. Financial-grade API – Part 2: Advanced Security Profile. OpenID Final Specification, approved 12 March 2021. Official identifier: OpenID FAPI 1.0 Advanced Final. Source type: official technical specification. Interest disclosure: the OpenID Foundation develops identity standards; authors and organisations may participate in the identity and financial-API ecosystem.
10. Open Banking Limited. Contract and Supplier Management. Good-practice guidance, version 4.0.1, published 18 March 2026. Official identifier: UK Open Banking Standard v4.0.1 good practice. Source type: official ecosystem good-practice guidance. Interest disclosure: OBL has an institutional interest in reliable ecosystem operation.
11. Open Banking Limited. Testing. Good-practice guidance, version 4.0.1, published 18 March 2026. Official identifier: UK Open Banking Standard v4.0.1 good practice. Source type: official ecosystem good-practice guidance. Interest disclosure: OBL has an institutional interest in conformance and reliable ecosystem operation.
12. Open Banking Limited. Business Continuity and Disaster Recovery. Good-practice guidance, version 4.0.1, published 18 March 2026. Official identifier: UK Open Banking Standard v4.0.1 good practice. Source type: official ecosystem good-practice guidance. Interest disclosure: OBL has an institutional interest in service resilience.
13. Open Banking Limited. Data Management. Good-practice guidance, version 4.0.1, published 18 March 2026. Official identifier: UK Open Banking Standard v4.0.1 good practice. Source type: official ecosystem good-practice guidance. Interest disclosure: OBL has an institutional interest in consistent data lifecycle management.
14. Information Commissioner’s Office. What needs to be included in the contract? Regulatory guidance, accessed 28 July 2026. Official identifier: UK GDPR controller-processor contracts guidance. Source type: regulator guidance. Interest disclosure: the ICO regulates UK information rights and data protection.
15. Information Commissioner’s Office. Personal data breaches: a guide. Regulatory guidance, updated for the Data (Use and Access) Act 2025 and accessed 28 July 2026. Official identifier: UK GDPR breach-reporting guidance. Source type: regulator guidance. Interest disclosure: the ICO receives and regulates personal-data breach notifications.
16. Financial Conduct Authority. Outsourcing and operational resilience. Supervisory web guidance, updated 14 July 2026. Official identifier: FCA outsourcing and operational-resilience guidance. Source type: regulator guidance. Interest disclosure: the FCA supervises operational resilience and outsourcing for regulated firms.
17. Information Commissioner’s Office. Marketing and data protection in detail. Regulatory guidance, undated web guidance accessed 28 July 2026. Official identifier: UK GDPR and PECR direct-marketing guidance. Source type: regulator guidance. Interest disclosure: the ICO regulates UK data protection and electronic marketing.
18. UK Payments Initiative Limited. cVRP Rulebook, version 3.0. Scheme rulebook, dated 16 April 2026. Official identifier: cVRP Rulebook v3.0. Source type: official scheme rulebook. Interest disclosure: UKPI operates the commercial VRP scheme and has a direct institutional and commercial interest in its operation. Note on the link: the hosted filename still reads “v1.0” for legacy reasons, but the document served at that address is Final version 3.0, dated 16 April 2026, and was verified on 28 July 2026.