Part 5

CUToday’s June 26 newsletter: Truliant FCU Faces Proposed Class Action Lawsuit Over Data Breach: WINSTON-SALEM, N.C.–Truliant Federal Credit Union faces a proposed class action lawsuit after a data breach reportedly exposed the private information of more than 48,000 members…

CUToday’s July 2 newsletter: ‘Serious Security Incident’ Leads to Major System Outage at Patelco Credit Union: DUBLIN, Calif.–Citing what it called a “serious security incident,” Patelco Credit Union said it was forced to shut down some of its online banking services over the weekend …

These two recent headlines are canaries in the coal mines telling us credit unions must give members more control over their data while better securing it. Using Open Banking’s Distributed Data Architecture, a credit union will give members more control over their data, enhance data security, and help prevent breaches and hacking. Here are some of the mechanisms:

Data Decentralization refers to data distribution across multiple independent nodes and systems rather than centralizing it in a single repository. Distributing data across various nodes and systems enhances security, resilience, and compliance while giving members greater control over their personal information. Here are the characteristics of Data Decentralization in Open Banking:

• Distributed Data Storage: Data is stored across various nodes/locations. These locations can be within the credit union’s network, across multiple financial institutions, or in cloud-based systems. Here are examples:
  • Node 1: Member Information Node
    • Location: Primary Data Center
    • Data Stored: Member personal details, account information (account numbers, account types), KYC (Know Your Member) documents (scanned IDs, proof of address), and member preferences and consent records
  • Node 2: Transaction Data Node
    • Location: Secondary Data Center
    • Data Stored: Transaction history (deposits, withdrawals, transfers,) transaction metadata (timestamps, transaction IDs, involved accounts,) fraud detection logs and flags, and transaction status (pending, completed, failed.)
  • Node 3: Financial Data Node
    • Location: Cloud Storage Provider (e.g., AWS, Azure)
    • Data Stored: Financial statements (monthly, quarterly, annual statements,) loan records (loan agreements, repayment schedules,) investment portfolios (asset details, performance data,) and interest rate history and calculations.
  • Node 4: User Authentication and Authorization Node
    • Location: On-Premises Security Server
    • Data Stored: user credentials (hashed passwords, PINs,) multi-factor authentication (MFA) data (e.g., OTP secrets, biometric data,) OAuth tokens and session data, and access control lists (ACLs) and role-based access control (RBAC) settings.
  • Node 5: Backup and Disaster Recovery Node
    • Location: Remote Data Center
    • Data Stored: Regularly updated backups of all critical data from other nodes, snapshot copies of databases and file systems, disaster recovery plans and scripts, and audit logs and backup integrity checks.

This distributed approach ensures that sensitive information is protected, services remain uninterrupted, and the credit union can efficiently manage and scale its data infrastructure through:

• Interoperability: Different systems and platforms can communicate and share data through standardized APIs and protocols, ensuring seamless integration and data exchange. How does interoperability in Practice work?
  • Transaction Processing: The Transaction Data Node logs a new transaction initiated by a member. The transaction details and metadata are then sent to the Financial Data Node to update the member’s financial records. The Transaction Data Node also updates the Member Information Node with the latest transaction history, ensuring the member’s account reflects the most recent activities.
  • Fraud Detection: Real-time transaction data from the Transaction Data Node is streamed to a centralized fraud detection system via a message broker like Kafka. If suspicious activity is detected, alerts are sent back to the Transaction Data Node and User Authentication Node, potentially triggering additional security measures or member notifications.
  • Data Analytics and Reporting: The Financial Data Node periodically exports financial records to a cloud-based analytics platform for performance analysis and reporting. The results of these analyses, such as trend reports and performance metrics, are then made available to the relevant nodes, such as the Member Information Node, to inform member communications and marketing strategies.
  • Backup and Recovery: Regular backups from each node are sent to the Backup and Disaster Recovery Node. This node ensures that data is securely stored and can be restored in the event of data loss or corruption in any primary node. The Backup Node uses secure protocols to verify the integrity and completeness of the backups, maintaining an up-to-date recovery plan.

Interoperability between nodes in a credit union’s distributed data architecture is critical for ensuring efficient, secure, and seamless operations. By leveraging standardized APIs, standard data formats, middleware, and robust security protocols, credit unions can achieve high integration and coordination across their systems, ultimately enhancing service delivery and operational resilience.

• Member Information Access—Data Ownership and Control: Member Information Access: When members log into their online banking portal, the User Authentication Node verifies their credentials. Once authenticated, the portal uses an OAuth token to securely request member details from the Member Information Node. The Member Information Node responds with the necessary data in JSON format, which is then displayed to the member. Members retain control over their data and decide which third parties can access it. This is facilitated through consent management frameworks.

Data ownership and control by members in a credit union are fundamental principles facilitated by consent management frameworks within the Open Banking paradigm. Here’s an example that illustrates how these concepts work in practice:

• A credit union member wants to use a third-party financial management app to analyze spending patterns and receive personalized budgeting advice. They must share their transaction history and account details with the app to do this. Here are the steps Involved:
  • Member Initiates Consent Process: The member logs into the financial management app and is prompted to link their credit union account to provide the necessary data. The app directs the member to the credit union’s consent management interface.
  • Authentication: The member is authenticated using multi-factor authentication (MFA) (e.g., entering a password and a code sent to their mobile phone).
  • Consent Request: The credit union’s consent management system presents the member with a detailed request outlining what data the third-party app wants to access. This includes:
    • Specific types of data (e.g., transaction history, account balances)
    • The purpose of data access (e.g., budgeting advice)
    • The duration of access (e.g., one-time, monthly updates)
    • The ability to select specific accounts if they have multiple accounts.
  • Granular Control: The member can allow or deny access to each data type requested. For instance, they might enable access to transaction history but deny access to loan details. The member can also set conditions, such as limiting access to transactions from the past three months.
  • Consent Confirmation: After selecting the permissions, the member reviews a summary of their choices and confirms their consent. The credit union system generates a consent token that encapsulates the permissions granted.
  • Data Access by Third Party: The third-party app uses the consent token to request data from the credit union’s API. The credit union’s system validates the token and checks that the requests comply with the member’s consent settings before providing the data.
  • Ongoing Control: Members can log into their credit union’s online portal anytime to view active consents. Through the consent management interface, they can revoke consent entirely or modify permissions (e.g., change data access from monthly updates to one-time access).
  • Transparency and Audit: The credit union provides a transparent log of all data accessed and shares it with the members so they can see which data was accessed, by whom, and when. The member receives notifications (e.g., via email or SMS) whenever their data is accessed by the third-party app, ensuring full awareness and control.

Through robust consent management frameworks, credit unions can facilitate data ownership and control by their members, ensuring that data sharing is secure, transparent, and aligned with the members’ preferences. This approach enhances the member experience and strengthens data privacy and regulatory compliance.

• Redundancy and Replication: Data is often replicated across multiple nodes to ensure availability and reliability. If one node fails, others can continue providing data access. Here’s an example of how data replication across multiple nodes can ensure availability and reliability at a credit union. Scenario – A credit union wants to ensure that its core banking system, including member account information, transaction history, and loan records, remains highly available and reliable, even during hardware failures or other disruptions.
  • Data Replication Mechanism
    • Real-Time Replication:
      • Primary to Secondary Data Center:
        • Method: Synchronous replication
        • Details: Any changes (inserts, updates, deletes) made in the primary data center’s database are immediately replicated to the secondary data center.
        • Purpose: Ensures zero data loss and immediate failover capability.
    • Near Real-Time Replication:
      • Primary to Cloud-Based Node:
        • Method: Asynchronous replication
        • Details: Changes in the primary data center’s database are periodically batched and replicated to the cloud-based node, with a slight delay to optimize cost and network usage.
        • Purpose: Provides an additional layer of redundancy with a minor delay acceptable for disaster recovery purposes.
• Ensuring Availability and Reliability
  • High Availability:
    • Automatic Failover: If the primary data center (Node 1) experiences a failure, the secondary data center (Node 2) automatically takes over as the primary data source. A load balancer or a database management system that supports failover mechanisms facilitates this switch.Continued Operations: Member transactions and services continue uninterrupted, as the secondary node has an up-to-date copy of all data.
    Disaster Recovery:
    • Data Backups: The cloud-based node (Node 3) ensures a reliable backup is in a geographically separate location. In a catastrophic failure affecting primary and secondary data centers, data can be restored from the cloud-based node.Periodic Testing: Regular disaster recovery drills are conducted to ensure the data can be restored from the cloud node within an acceptable recovery time objective (RTO).
  • Consistency and Integrity:
    • Data Integrity Checks: Regular integrity checks and consistency validations are performed between nodes to ensure data remains accurate across all replicas.
    • Conflict Resolution: In asynchronous replication, mechanisms are in place to resolve conflicts and ensure that the most recent data is propagated correctly across all nodes.

Here is a workflow example:

1. Member Transaction: A member deposits money into their account. This transaction is immediately recorded in the primary data center (Node 1).
2. Synchronous Replication: The transaction is simultaneously replicated to the secondary data center (Node 2).
3. Asynchronous Replication: The transaction is in the next batch update to the cloud-based node (Node 3).

Primary Data Center Failure: If the primary data center (Node 1) goes offline due to a power outage, the secondary data center (Node 2) automatically takes over. Members continue to access their accounts and perform transactions without interruption, as Node 2 has the latest data.

Disaster Recovery: In the unlikely event that both Node 1 and Node 2 fail, the credit union activates its disaster recovery plan. Data is restored from the cloud-based node (Node 3) to a new or repaired primary data center. The system continues functioning with minimal data loss and downtime, adhering to predefined RTOs and recovery point objectives (RPOs).

The benefits include:

• Uninterrupted Service: Members experience seamless service even during hardware failures or other disruptions.
• Data Redundancy: Multiple copies of data reduce the risk of data loss, ensuring that the credit union can swiftly recover from failures.
• Regulatory Compliance: Ensures compliance with regulations requiring data redundancy and disaster recovery plans.
• Operational Efficiency: Automating failover and data replication processes minimizes manual intervention and operational overhead.

A credit union can ensure the high availability, reliability, and resilience of its core banking system by implementing a robust data replication strategy across multiple nodes. This approach enhances member trust and satisfaction and safeguards against data loss and service interruptions.

Benefits of Data Decentralization in Open Banking

Enhanced Security:

• Reduced Single Point of Failure: Decentralizing data reduces the risk of a single breach compromising the entire dataset. An attacker would need to breach multiple systems to access all the data.
• Improved Data Privacy: Sensitive data is not stored in one central location, making it harder for unauthorized entities to access comprehensive information about individuals.
• Resilience and Availability:
  • Fault Tolerance: Distributed systems are more resilient to failures. If one part of the system goes down, other parts can continue to function, ensuring continuous availability of services.
  • Disaster Recovery: Data replication across multiple locations ensures that data can be recovered even if one area is compromised or fails.
• Scalability:
  • Horizontal Scaling: Decentralized systems can scale more easily by adding more nodes to handle increased load, improving performance and capacity.
  • Flexible Infrastructure: Financial institutions can leverage various infrastructure options, including cloud services, to optimize cost and performance.
• Data Sovereignty and Compliance:
  • Local Compliance: Data can be stored in specific geographic locations to comply with local regulations and data sovereignty laws.
  • Granular Control: Institutions can manage data access and usage more granularly, ensuring compliance with regulatory requirements like GDPR and PSD2.
• Implementation in Open Banking
  • APIs and Open Standards: Financial institutions implement APIs based on open standards to enable secure and standardized data sharing across different platforms and services.
  • Consent Management: Members provide explicit consent for data sharing, and their preferences are respected and enforced through decentralized systems.
  • Blockchain and Distributed Ledger Technologies: Some Open Banking systems use blockchain technology to ensure data integrity, immutability, and transparency in transactions and data sharing.

Data decentralization in Open Banking fundamentally transforms how financial data is managed, shared, and secured. Distributing data across multiple nodes and systems enhances security, resilience, and compliance while giving members greater control over their personal information. The result is a Reduced Single Point of Failure. Unlike centralized systems, where a single breach can compromise the entire dataset, distributed data is stored across multiple locations, making it difficult for attackers to access all the information in one go. In addition, there is Improved Redundancy of the data. If one node is compromised, others can maintain the integrity and availability of data.