Account Hierarchy Aggregation via Pre-computed Parent Relationships
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Large server systems face challenges in efficiently grouping transactions across account hierarchies without prior indication of account relationships, leading to inefficient data analysis and categorization.
Innovation Solution
The system determines the ultimate parent organization for each account and compares source addresses to identify sibling accounts, grouping transactions based on shared ultimate parents and source addresses, and re-categorizes transactions by replacing account IDs with a minimum account number for aggregation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If real-time analysis is performed to group transactions without prior account relationship indication, then transaction categorization accuracy is improved, but system processing time and computational resources increase
Solution Approach 1:
The system performs preliminary actions by pre-computing and storing account hierarchy relationships (parent-child connections, sibling relationships, ultimate parent identification) in the database before transaction analysis is needed. This allows transactions to be grouped efficiently by joining with pre-computed account relationship data rather than performing complex real-time analysis of account hierarchies during transaction processing.
Solution Approach 2:
The system introduces intermediary account hierarchy tables that store pre-computed relationship data (account relationships, ultimate parent accounts, sibling groupings) as a mediator between raw transaction data and final categorized results. These intermediary tables enable efficient joins and groupings without requiring complex real-time hierarchy traversal.
2Measurement precision
If complex account hierarchy analysis is performed to determine sibling relationships, then transaction grouping accuracy is improved, but database query complexity increases
Solution Approach 1:
The system pre-computes complex account hierarchy attributes (ultimate parent account, sibling relationships, hierarchical level) and stores them in the account relationships table before they are needed for transaction analysis. This transforms complex hierarchical queries into simple joins with pre-computed data.
Solution Approach 2:
The account relationships table serves as an intermediary that stores pre-computed hierarchical relationships, allowing transaction grouping to be achieved through simple joins rather than complex recursive queries. The intermediary table captures the results of complex hierarchy analysis in a query-friendly format.
3Reliability
If transactions are grouped by account relationships, then data storage compliance and pricing accuracy are improved, but data processing complexity increases
Solution Approach 1:
The system pre-computes and stores account hierarchy relationships including ultimate parent identification and sibling groupings before transaction aggregation is needed. This allows compliance-critical groupings to be determined through simple joins with pre-computed relationship data rather than complex processing during data storage operations.
Data Source
AI summary
System and methods for aggregating key metrics across an account hierarchy are disclosed. The server system accesses a first transaction record, wherein the first transaction is categorized into a first category. The server system analyzes an account record associated with the first account to determine a parent account of the first account. The server system identifies a second transaction record associated with a second account. The server system compares a first address of record for the first account to a second address of record for the second account. In accordance with a determination that the first address of record matches the second address of record, the server system aggregate the first transaction and a second transaction listed in the second transaction record into a combined transaction. The server system categorizes the combined transaction into a second category, wherein the second category is different from the first category.