Granular Data Access Control via Segmented Aggregator Profiles

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing data access request processing methods in open banking lack granular control over user data access, often requiring modifications to configuration files and lacking dynamic control over API access for third-party applications.

Innovation Solution

A computing platform and method that utilize a combination of user account authorization tokens and aggregator access profiles to determine and transmit access permissions to data aggregators, allowing granular access control through HTTP modifications using verbs and URIs, enabling selective API and data type access without modifying configuration files.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If traditional data access methods are used in open banking, then data sharing between financial institutions and third-party applications is enabled, but granular control over user data access is lacking

Engineering Contradiction:
Improvegranular control over data accessVSAvoidaccess control mechanism complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The access control mechanism is segmented into two distinct components: aggregator access profiles (defining which APIs the data aggregator can access) and user account authorization tokens (defining which user accounts the aggregator can access). This segmentation enables granular control over data access while maintaining manageable system complexity through clear separation of concerns.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If configuration files are modified to change API access permissions, then access control can be adjusted, but the process requires manual modifications and lacks dynamic control

Engineering Contradiction:
Improvedynamic access controlVSAvoidconfiguration modification process
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The system transitions from static configuration file modifications to dynamic access control through programmatically generated aggregator access profiles and user account authorization tokens. These can be created, modified, and revoked dynamically without manual configuration file changes, enabling flexible and responsive access control management.

Inventive Principle:
Principle #15Dynamics

3Ease of operation

If tokens are issued per financial institution-aggregator pair, then data access management is simplified, but granular control over specific user accounts and APIs is reduced

Engineering Contradiction:
Improvedata access managementVSAvoidgranular access control
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The traditional single-token approach is segmented into two independent components: aggregator access profiles (managed at the aggregator level) and user account authorization tokens (managed at the user account level). This segmentation enables both ease of management through modular components and granular control through specific pairing of profiles and tokens for each API and user account combination.

Inventive Principle:
Principle #1Segmentation

4Adaptability or versatility

If broad access permissions are granted to data aggregators, then third-party application functionality is enhanced, but user data protection is compromised

Engineering Contradiction:
Improvethird-party application functionalityVSAvoiduser data protection risk
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

Access permissions are assigned with local quality, meaning each aggregator access profile and user account authorization token specifies exactly which APIs and user accounts are accessible. This enables third-party applications to receive precise, minimal necessary access rights for their specific functionality needs while automatically excluding access to unrelated user data, thereby protecting user privacy while enabling application functionality.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS20230101530A1System and method of processing a data access request
Publication Date: 2023.03.30 THE TORONTO DOMINION BANK
  • US20230101530A1 patent drawing
  • US20230101530A1 patent drawing
  • US20230101530A1 patent drawing

AI summary

Computing platforms, methods, and storage media for processing a data request are disclosed. Exemplary implementations may: receive a data transfer request including data transfer instructions associated with the data transfer; obtain an aggregator access profile specifying application programming interface (API) access to be granted to a data aggregator with respect to one or more APIs; obtain a user account authorization token specifying access to be granted to the data aggregator with respect to one or more user accounts; determine access permissions associated with the data transfer instructions based on a combination of the aggregator access profile and the user account authorization token; and transmit an access notification based on the determined access permissions, the access notification specifying the combination of the one or more APIs and the one or more user accounts to which the data aggregator is granted access. Application-specific account permissions and data type permissions may be specified.