Who Owns the Data? Unlocking Open Finance Without Compromising Consent

Section 1: Executive Summary & The Shift to Open Finance

The global financial services industry is undergoing an irrevocable structural transformation: the migration from closed, proprietary banking silos to open, interconnectable data ecosystems. Historically, Financial Services Providers (FSPs) maintained complete, walled control over client account histories, portfolio structures, and transactional records. Today, customer-directed data portability is dismantling these traditional boundaries. Driven by evolving regulatory frameworks and shifting consumer expectations, data is transitioning from an institutionally guarded balance-sheet asset into a customer-owned utility that must flow freely across licensed platforms at the account holder’s explicit command.

This structural shift introduces a profound operational paradox for FSPs, wealth managers, and compliance officers:

Clients increasingly demand hyper-personalised, real-time financial management that aggregates held-away banking, investment, insurance, and pension assets into unified planning platforms. Simultaneously, the proliferation of high-profile data breaches, combined with stringent enforcement under legislation such as the Protection of Personal Information Act (POPIA) and the General Data Protection Regulation (GDPR), has elevated data privacy to an all-time regulatory priority. Financial institutions are squeezed between the commercial imperative to innovate via data sharing and the strict legal exposure associated with handling sensitive financial data.

For key decision-makers, wealth practice leads, and Key Individuals (KIs), understanding Open Finance and data sovereignty is no longer an isolated IT responsibility or a back-office technical detail. Instead, data governance and consent architectures have emerged as fundamental elements of Treating Customers Fairly (TCF), market conduct, and operational liability.

Relying on legacy practices, such as unencrypted screen-scraping or passive, blanket “terms and conditions” checkboxes, exposes FSPs to catastrophic regulatory penalties, civil liability for third-party data breaches, and severe reputational damage. Mastering the balance between frictionless data portability and robust, purpose-bound consent protocols is now a primary requirement for delivering competent, compliant financial advice in a modernised market.

Section 2: Macro Landscape: Regulatory Drivers and Local Realities

Understanding Open Finance requires examining the shift in legal paradigms from global standards to domestic practice. Financial data is no longer held exclusively by single institutions; it now operates across interconnected networks governed by strict data rights and regulatory requirements.

Global Benchmarks

The modern Open Finance architecture stems from European regulatory precedents designed to increase market competition and protect consumer data sovereignty:

• The UK OBIE Framework: The establishment of the Open Banking Implementation Entity (OBIE) under the Competition and Markets Authority (CMA) mandate created a standardised approach to application programming interfaces (APIs). By forcing the UK’s nine largest banks to share standardised, read-only and transactional customer data with accredited Third-Party Providers (TPPs), the OBIE proved that open data sharing can coexist with system stability.
• The EU PSD2 to PSD3 Evolution: The European Union’s Revised Payment Services Directive (PSD2) legally mandated bank-led API access for account information and payment initiation. However, its practical limitations led to the development of PSD3 and the Financial Data Access (FiDA) regulation framework. This transition explicitly expands coverage beyond standard transactional payment accounts to encompass comprehensive Open Finance, incorporating discretionary investments, private pensions, long-term savings, and insurance policies under a unified data portability regime.

Domestic Frameworks and the Local Reality

In South Africa, the regulatory architecture for Open Finance is developing at the intersection of data privacy legislation and conduct-based oversight.

SOUTH AFRICAN OPEN FINANCE GOVERNANCE DUALITY

1. POPIA vs. FSCA Regulatory Alignment

The Protection of Personal Information Act 4 of 2013 (POPIA) grants data subjects strict rights regarding how their personal financial information is processed, stored, and shared. Under POPIA, processing financial history requires an ongoing, legally valid condition, most commonly explicit, informed consent.

Concurrently, the Financial Sector Conduct Authority (FSCA) is developing a formal Open Finance regulatory framework. Aligned with the forthcoming Conduct of Financial Institutions (COFI) Bill, the FSCA’s policy approach shifts focus towards customer outcomes, mandatory operational standards for data providers, and proportionate licensing for non-bank Third-Party Providers (TPPs).

2. The Elimination of Screen-Scraping

Historically, third-party aggregation relied on “screen-scraping”; a practice where clients provided their raw online banking credentials (usernames and passwords) to software intermediaries, which then automatically logged into web portals to harvest display data.

OLD MODEL: Screen-Scraping (High Liability)

Client → (Provides Passwords/PINs) → Aggregator → (Scrapes Portal) → Bank Server • Exposes raw credentials • Violates bank terms & conditions • Lacks granular, time-bound consent controls

NEW MODEL: Direct API Federation (Secure Governance)

Client → (OAuth Token/Consent) → Regulated API → (Encrypted Data Payload) → Advisers/FSPs • Zero credential sharing • Granular, revocable access scopes • Full cryptographic auditability

Screen-scraping poses significant regulatory and security vulnerabilities:

• It forces clients to breach standard banking customer agreements regarding credential secrecy.
• It provides binary “all-or-nothing” account access rather than limited, read-only permissions.
• It leaves no cryptographic audit trail of which specific data points were extracted.

The South African market is actively transitioning away from screen-scraping toward standardised, secure Open APIs utilizing OAuth 2.0 and Mutual TLS (mTLS) security standards. This shift ensures that access is granted via secure tokens rather than shared passwords.

Redefining Data Sovereignty: The Operational Lease Model

To maintain compliance across this regulatory landscape, FSPs must update how they view customer records:

Core Principle of Financial Data Sovereignty: Financial customer data is an immutable asset owned exclusively by the customer. When a client shares their financial history with an FSP or wealth manager, they do not assign ownership of that information. Instead, they grant a limited, temporary operational lease governed strictly by the purpose specified at the time of consent.

DATA SOVEREIGNTY LEASE

Owner: Financial Customer (Data Subject) Lessee: Financial Services Provider (FSP) Scope: Read-Only Consolidated Wealth Analysis Duration: 90-Day Auto-Expiring OAuth Token Revocation: Unilateral / Instant via Client Portal

As this access operates as a temporary lease, FSPs act solely as custodians of the data. If the client revokes consent, or if the underlying processing purpose expires, the FSP’s legal basis to harvest or process updated data feeds immediately terminates. Treating customer data as a leased asset rather than proprietary company property is the foundation of compliant Open Finance management.

Section 3: The Mechanics of Modern Consent Management

As Open Finance transitions from theoretical framework to active market infrastructure, consent management shifts from a legal formality into a core operational discipline. Capturing and maintaining client consent can no longer rely on static paper disclosures or burdensome onboarding processes. For Financial Services Providers (FSPs) and wealth management practices, operationalising consent requires building transparent, digital-first workflows that comply with data privacy legislation while maintaining a smooth user experience.

Beyond the T&Cs Checklist: Unbundling Consent

For decades, financial institutions relied on catch-all legal terms: expansive, multi-page terms and conditions documents where a single signature granted blanket authorisation to collect, store, profile, and cross-sell client data.

Under modern regulatory standards (such as POPIA Section 11 and GDPR Article 7), bundled consent is legally invalid. FSPs cannot condition the delivery of a financial planning service on the client agreeing to unrelated data processing activities.

BUNDLED CONSENT (NON-COMPLIANT)

[X] I agree to the Terms & Conditions, Privacy Policy, automated credit checks, third-party marketing sharing, and continuous data harvesting.   (Single mandatory checkbox)

UNBUNDLED CONSENT (COMPLIANT)

[X] Mandatory: I authorize the collection of bank transaction data solely for preparing my annual financial plan.   Optional: I consent to sharing portfolio metrics with affiliated tax partners. Optional: I agree to receive monthly market commentary and product updates.

Compliance requires clear unbundling:

• Primary Service Processing: Necessary for executing the direct financial advice or management agreement (e.g., aggregating investment portfolios to perform a retirement suitability assessment).
• Secondary Value-Add Processing: Optional activities requiring independent, opt-in consent toggles (e.g., sharing cash-flow summaries with an external tax consultant or using transaction data for predictive product marketing).

The Anatomy of Valid Consent

To withstand legal scrutiny and regulatory audits, every consent workflow built into an FSP’s client portal or onboarding software must meet three structural criteria:

THE TRIAD OF VALID CONSENT

1. Specific and Informed (Granular Scope)

Consent must clearly define the parameters of data access. Clients must explicitly see and approve:

• Data Scopes: Distinguishing clearly between read-only account balances, detailed transaction histories, and identity verification credentials.
• Recipient Identity: Identifying the exact legal entities that will process the data, including intermediary API aggregators and software vendors.
• Purpose Boundary: Explicitly stating why the data is being collected (e.g., “To perform dynamic budget analysis for retirement cash-flow projections”).

2. Time-Bound and Dynamic Management

Consent cannot be perpetual. Open Finance frameworks require FSPs to establish automated consent lifecycles:

• Fixed Authorisation Windows: Mandating active client re-authorisation at fixed intervals (typically every 90 to 180 days).
• Automated Expiry Workflows: Systemic triggers that suspend third-party API data feeds immediately if a client fails to re-authenticate, preventing passive, forgotten background data collection.

3. Frictionless Revocation

Under POPIA Section 11(2)(b), a data subject has the statutory right to withdraw consent at any time, without penalty.

The Symmetry Rule: Withdrawing consent must be as simple, direct, and frictionless as granting it. If a client can grant consent via a two-click digital portal, the FSP cannot require a physical letter, call centre queue, or complex administrative process to cancel that permission.

Audit Trails and Compliance Evidence

During a regulatory inspection or following a reported data incident, the onus of proof rests entirely on the FSP. Under Section 11(3) of POPIA, the responsible party must prove that valid consent was obtained. Compliance teams must maintain tamper-evident, immutable audit records for every data transaction.

Audit Record Field	Required Log Entry Standard	Compliance Purpose
Timestamp & Version	UTC ISO 8601 timestamp paired with the exact version of the consent text displayed.	Proves the precise legal wording the client agreed to at that moment.
Authentication Method	Multi-Factor Authentication (MFA) log, OAuth token ID, or digital signature hash.	Confirms the identity of the individual granting consent.
Scope Log	Exact matrix of granted permissions (e.g., Read_Balances: True, Read_Transactions: False).	Validates that data collection remained strictly within approved boundaries.
IP & Device ID	Encrypted IP address and browser/device fingerprint metadata.	Assists in forensic verification during liability disputes.
Lifecycle State	Current status indicator (Active, Expired, Revoked, Re-authorised).	Demonstrates real-time enforcement of client choices.

By embedding these granular logs directly into their CRM and compliance management software, FSPs protect their practice against regulatory fines and establish an auditable record of compliant data processing.

Section 4: Operationalising Data Aggregation in Holistic Advice

While robust consent management establishes the legal framework for data sharing, the practical value of Open Finance lies in its implementation within daily financial planning and wealth management. Integrating secure API data feeds directly into client relationship management (CRM) systems, financial planning software, and portfolio management engines changes how financial advisers deliver advice. However, operationalising this data requires managing technological capabilities alongside legal and liability considerations.

Unlocking 360-Degree Client Wealth Views

Historically, advisers struggled with fragmented client data. High-net-worth individuals and retail investors frequently hold assets across multiple retail banks, linked investment services providers (LISPs), offshore wealth platforms, private equity vehicles, and traditional life insurers. Gathering an accurate view of a client’s complete financial situation required manually pulling statements, relying on client self-reporting, or waiting for delayed quarterly valuations.

INDEPENDENT FINANCIAL ADVISER (Central Planning Engine/CRM)

Open Finance APIs replace these manual approaches with automated, real-time data feeds:

• Comprehensive Asset & Liability Consolidation: API integrations directly aggregate held-away assets, including foreign currency accounts, retirement annuities, and mortgage liabilities, into a central planning platform. This eliminates manual data entry errors and provides an updated balance sheet for every client review.
• Dynamic Suitability & Cash-Flow Modelling: Modern financial planning requires accurate, current data. Real-time transaction and valuation feeds allow advisers to conduct cash-flow analyses, assess debt-to-income ratios, and perform stress testing based on verified portfolio values rather than outdated static balances.
• Automated Asset Allocation Drift Monitoring: By continually receiving position updates from third-party LISPs and platforms, advice systems can automatically alert portfolio managers when a client’s target asset allocation drifts beyond agreed risk parameters. This enables timely rebalancing and improves ongoing governance.

Data Accuracy vs. Adviser Liability

The operational efficiency gained from automated data feeds introduces important liability questions regarding data integrity. When an adviser bases recommendations, such as retirement income drawdowns or tax-loss harvesting, on third-party API data, who carries the risk if that data contains errors?

THE ADVISER LIABILITY RISK

1. Managing Data Discrepancies and Feed Latency

API data feeds can experience technical interruptions, schema changes, or synchronisation delays. An API feed from a third-party platform might report an outdated balance due to a processing delay, or fail to account for pending settlement transactions. If an adviser makes recommendations based on unverified, corrupted, or delayed data, they risk delivering unsuitable advice under the Financial Advisory and Intermediary Services (FAIS) Act or equivalent international conduct standards.

2. Delineating Liability in Client Service Level Agreements (SLAs)

To manage these operational risks, FSPs must update their client mandates and advice contracts. Advice agreements should clearly outline the scope and limits of aggregated data usage:

ADVISOR DATA LIABILITY CLAUSE

Data Source Validation: Automated API feeds are supplementary information sources. Verification Thresholds: Advice involving liquidations or transfers requires direct institutional statement confirmation. Client Duty to Disclose: The client remains responsible for disclosing unlinked accounts or unrecorded manual liabilities.

Data Security at the Interface

Connecting internal advice systems to external Open Finance networks expands an FSP’s threat surface. Securing these touchpoints requires technical safeguards across the entire data pathway.

                                                      Mutual TLS (mTLS)             AES-256 at Rest

API Endpoint Hardening: Intermediary connections must run over TLS 1.3 encryption using Mutual TLS (mTLS) authentication. This ensures that both the sending institution and the receiving FSP cryptographically verify their identity before transmitting data.

Middleware and Aggregator Isolation: FSPs should avoid connecting core databases directly to external APIs. Instead, incoming data feeds should land in an isolated middleware environment, where data payloads are sanitised, validated against schema standards, and checked for unexpected entries before moving into central planning platforms.

Storage Security Protocols: Once data reaches the FSP, it must be secured using AES-256 encryption at rest, backed by strict Role-Based Access Controls (RBAC). Advisers and support staff should only access data fields necessary for their specific roles, following the principle of least privilege required by POPIA and GDPR.

Section 5: Risk, Liability, and Ecosystem Governance

Operating within an Open Finance ecosystem changes the risk profile of a Financial Services Provider (FSP). As data flows across interconnected application programming interfaces (APIs), third-party aggregators, and cloud-native wealth platforms, the traditional security boundary expands. Managing compliance and operational risk requires looking beyond internal IT controls to govern the entire data distribution chain.

Tracing Liability Across the Data Chain

When a data breach occurs, identifying where responsibility lies requires analysing the technical and contractual links across the data supply chain. A typical Open Finance interaction involves multiple autonomous entities:

Potential Breach Points

Under POPIA and GDPR, the party that determines the purpose and means of processing personal information remains the primary Responsible Party (or Data Controller). If an FSP instructs a client to connect their bank accounts via an aggregator to produce a financial plan, the FSP carries primary accountability to the client for how that data is collected and safeguarded.

However, liability downstream depends on contractual terms and fault:

• The Primary Data Holder (Bank/LISP): Responsible for maintaining secure API endpoints. If a vulnerability at the bank level exposes credentials before transmission, liability sits with the issuing institution.
• The Intermediary Aggregator: Acts as an Operator (Data Processor). If a data leak occurs due to unencrypted storage or security flaws on the aggregator’s servers, the FSP retains regulatory responsibility to the data subject, but holds a right of recourse against the aggregator under their Data Processing Agreement (DPA).
• The Advice Practice (FSP): Liable if data is compromised due to weak internal user controls, unencrypted local downloads, or shared employee credentials.

Third-Party Vendor Due Diligence

FSPs cannot delegate their legal responsibilities under data protection law. Consequently, vetting external API aggregators, wealth software vendors, and cloud connectors is a mandatory compliance requirement.

THIRD-PARTY VENDOR DEDICATED MATRIX

Key Technical & Security Vetting Criteria

1. Independent Security Standards: Verify that the aggregator maintains current ISO/IEC 27001 certification or a SOC 2 Type II audit report covering system security, availability, and confidentiality.
2. Data Minimisation Capabilities: Ensure the vendor allows the FSP to strip unneeded identifiers (such as national ID numbers or full account numbers) before storing data payloads.
3. Geographic Data Residency: Confirm where server infrastructure is located. Under POPIA Section 72, transferring personal information outside South Africa requires ensuring the recipient country maintains adequate data protection laws or that binding agreements enforce equivalent protections.

Mandatory Data Processing Agreement (DPA) Clauses

Every third-party software contract must contain an explicit DPA that binds the vendor to strict operational limits:

Essential DPA Clause	Legal and Operational Mandate
Purpose Limitation	Prohibits the vendor from monetising, aggregating, or sub-licensing extracted client data for secondary commercial purposes.
Breach Notification Timelines	Requires the vendor to notify the FSP in writing within a strict timeframe (e.g., 24 to 48 hours) of any suspected or confirmed data incident.
Right to Audit	Grants the FSP (or its designated independent auditor) the right to review the vendor’s security logs, penetration test results, and compliance controls annually.
Data Return & Destruction	Guarantees that upon contract termination, all cached client financial data is permanently deleted using cryptographic erasure standards.

Cyber Resilience and Breach Response

As zero-risk environments do not exist in digital financial networks, regulatory compliance requires demonstrating operational resilience; the capability to detect, contain, and recover from data incidents quickly.

1. Integrating Open Finance Partners into Incident Response

FSPs must extend their Incident Response Plans (IRP) beyond internal systems to include external data partners. Cyber response playbooks should establish clear technical escalation paths:

• API Suspension Protocol: Automated “kill switches” that immediately sever third-party API connections if unusual data extraction volumes or unauthorised access attempts are flagged.
• Isolated Data Containment: Segmenting compromised databases to prevent lateral movement across the FSP’s core network.

2. Regulatory and Client Notification Protocols

When a data breach occurs at the API or aggregator level, the FSP must execute statutory disclosure workflows without delay:

DATA BREACH IDENTIFIED

FSPs must provide affected clients with actionable advice—such as placing fraud alerts on credit profiles or revoking specific digital tokens—to help mitigate financial risk following exposure.

Section 6: Strategic Roadmap, Practical Takeaways & Conclusion

The transition toward Open Finance represents a fundamental shift in how financial advice, wealth management, and client relationships operate. As data sovereignty moves firmly into the hands of the consumer, Financial Services Providers (FSPs) can no longer view data access as a simple technical integration or a back-office administration item. Instead, managing Open Finance APIs and consent structures is a strategic discipline that directly impacts an FSP’s regulatory standing, market competitiveness, and client trust.

To navigate this evolving environment effectively, FSPs, Key Individuals (KIs), and compliance officers must take proactive, structured steps. The following four-step framework provides an actionable implementation plan for practices adapting to an open data ecosystem:

Step-by-Step Actionable Implementation Roadmap

FSP OPEN FINANCE ROADMAP

1. Data Tooling & Scraping Audit → Audit current tools & phase out legacy scraping

2. Consent Portal Upgrade → Deploy unbundled, dynamic consent workflows

3. Client Agreement Refinement → Update SLAs to define liability & data boundaries

4. Vendor Vetting & Resilience → Conduct DPA reviews & integrate API kill switches

Step 1: Audit Current Data Aggregation Tools and Software

Conduct an immediate inventory across the practice to identify every software platform, CRM plug-in, and portal used to gather client financial information.

• Identify any lingering reliance on credential-sharing or screen-scraping tools.
• Establish a clear sunset timeline to replace legacy scrapers with certified, tokenised Open APIs, mitigating potential bank terms-of-service violations and security vulnerabilities.

Step 2: Upgrade Consent Capture Interfaces and Workflows

Transition client onboarding and annual review workflows away from blanket, bundled terms and conditions toward unbundled, granular consent architectures.

• Implement active opt-in mechanisms that separate primary advice processing from secondary value-add activities.
• Build automated 90-to-180-day re-authorisation workflows and ensure clients can revoke access at any time through a clear, one-click digital option.

Step 3: Refine Client Service Level Agreements (SLAs)

Review and update standard client engagement contracts, financial planning mandates, and disclosure documents to account for API-driven data integration.

• Clearly define the boundary between automated API data aggregation and final adviser verification responsibilities.
• Reiterate the client’s ongoing duty to disclose unlinked assets, manual liabilities, and unintegrated holdings to ensure advice remains accurate and suitable.

Step 4: Execute Third-Party Vendor Audits and Incident Playbooks

Perform thorough due diligence on all external fintech vendors, aggregator platforms, and software providers connected to the FSP’s systems.

• Ensure signed Data Processing Agreements (DPAs) include purpose-limitation clauses, strict breach notification windows, and clear audit rights.
• Update the practice’s Incident Response Plan (IRP) to include automated API “kill switches” and explicit regulatory disclosure protocols in the event of an external aggregator breach.

Strategic Conclusion: Data Governance as a Competitive Advantage

The shift to Open Finance ultimately requires FSPs to look past immediate compliance burdens and recognise the broader strategic opportunity. While meeting the requirements of POPIA and FSCA market conduct frameworks is mandatory, establishing transparent, client-centric data practices can serve as a key business differentiator.

In a market where consumers are increasingly aware of data privacy risks, demonstrating clear stewardship of personal financial information builds long-term trust. Clients who feel confident that their data is secured through tokenised APIs, used strictly for agreed purposes, and easily revocable are far more likely to share their complete financial picture. This openness allows wealth managers to deliver truly holistic, 360-degree advice that encompasses held-away assets, offshore accounts, and complex liabilities, improving the quality and relevance of their planning.

Conversely, FSPs that rely on outdated data collection methods or obscure consent terms risk regulatory penalties, civil liability, and reputational damage. As the South African financial sector moves closer to full Open Finance integration under COFI, data sovereignty shifts from a technical detail to a core marker of professional competence. By adopting secure API architectures, unbundled consent management, and rigorous third-party risk controls, FSPs can protect their practices while unlocking the full power of real-time financial planning.

For more information on this key topic, watch our informative podcast below.