Registry-Mediated Push of Detailed Transaction Data
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current standards for exchanging transactional information, such as OFX, do not support detailed transactional data access and require point-to-point connections, leading to bottlenecks and overhead when dealing with multiple service providers, and accessing detailed transactions is difficult due to a 'pull' model.
Innovation Solution
A system using secure identifiers generated from user identifiers, a registry mapping these to data stores, and a registry that facilitates the discovery of data store locations, allowing entities to push detailed transactions without pre-existing connections, with configurable validation and alerting rules.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If point-to-point connections are used to exchange transactional data between service providers and users, then direct data exchange is enabled, but the system complexity and overhead grow proportionally with the number of participating organizations
Solution Approach 1:
The patent introduces a registry as an intermediary component that mediates between service providers and users. The registry stores mappings between user identifiers and data store locations, allowing service providers to push transactions without establishing direct point-to-point connections. This eliminates the need for complex direct connections between all participants while maintaining reliable data exchange through the intermediary registry system.
2Ease of operation
If point-to-point connections are established for each service provider, then direct access to user data is achieved, but authentication and account maintenance overhead increases substantially
Solution Approach 1:
The system enables self-service through the registry, which automatically resolves user identifiers to data store locations without requiring manual authentication for each transaction. Service providers can independently push transactions by querying the registry, eliminating the need for continuous authentication overhead and account maintenance between multiple parties.
3Ease of operation
If a pull model is used to access detailed transactional information, then explicit requests can be made to financial institutions, but timely collection of dispersed transactions becomes difficult or impossible
Solution Approach 1:
The patent inverts the traditional pull model by implementing a push model where service providers automatically push transactions to the registry. Instead of users or systems actively querying for transactions, the system passively receives pushed transactions from multiple service providers, dramatically improving transaction collection efficiency and enabling timely access to dispersed transactional data.
4Loss of information
If detailed transactional data is made accessible across multiple service providers, then comprehensive analytics become possible, but security risks increase without proper protection mechanisms
Solution Approach 1:
The patent applies local quality by implementing validation rules that are specific to each user identifier or transaction type. The registry can enforce different security policies and validation criteria for different users or data stores, allowing comprehensive data accessibility while maintaining targeted security controls. This enables differentiated access permissions and validation requirements for different portions of the system.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
A system may include transaction storage devices. Each transaction storage device may include a data store configured to receive a request, from a service provider, to push a detailed transaction corresponding to a secure identifier. The secure identifier may be generated, using an encoding function, from a user identifier of a user. The data store may be further configured to store the detailed transaction based on a determination that the detailed transaction is valid. The system may further include a validator configured to obtain, from a registry, a validation rule corresponding to the secure identifier, and perform the determination. The determination may include applying the validation rule to the request. The system may further include the registry. The registry may be configured to store at least the validation rule.