Unified Transaction Processing System for Heterogeneous Financial Instruments

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current transaction processing systems in the financial industry are inefficient due to their inability to process multiple financial instrument types in a single system, leading to high integration costs, limited scalability, and difficulty in achieving real-time operations.

Innovation Solution

A transaction processing system that enables real-time, continuous processing of heterogeneous financial products across a single platform, integrating legacy systems and allowing for flexible component selection, while providing a phased path for retiring legacy systems and consolidating multiple vendor systems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple settlement engines are used to process different financial instrument types, then each instrument type can be processed by its dedicated engine, but the system complexity increases and integration costs rise

Engineering Contradiction:
Improveability to process different instrument typesVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal transaction processing system that can handle multiple financial instrument types (stocks, bonds, futures, options) through a single platform. The system uses a unified transaction engine with standardized data models and processing logic that adapts to different instrument types, eliminating the need for separate dedicated engines for each instrument category.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent consolidates multiple settlement engines and processing functions into a single integrated transaction processing system. By merging previously separate systems into one unified platform, the invention reduces the number of moving parts, lowers integration costs, and simplifies the overall system architecture while maintaining the ability to process diverse financial instruments.

Inventive Principle:
Principle #5Merging (Combining)

2Reliability

If separate systems are used for different financial products, then each system can be optimized for its specific product, but integration becomes expensive and difficult

Engineering Contradiction:
Improveproduct-specific optimizationVSAvoidintegration cost
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The patent segments the transaction processing system into modular components that can independently handle different financial instrument types while maintaining a unified architecture. This segmentation allows the system to preserve product-specific optimizations through configurable processing logic and data models, while the modular design enables easier integration and lower costs compared to monolithic separate systems.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent employs parameter changes and configuration mechanisms that allow the unified system to adapt its processing parameters based on the specific financial instrument type. By changing system parameters and configuration settings rather than requiring separate hard-coded systems, the invention achieves product-specific optimization while maintaining a single integrated platform that is easier and less expensive to implement.

Inventive Principle:
Principle #35Parameter changes

3Productivity

If batch processing is used, then processing can be completed, but down time occurs and real-time operations are limited

Engineering Contradiction:
Improveprocessing completionVSAvoiddown time
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent implements continuous transaction processing that operates in real-time as transactions occur, eliminating the need for periodic batch processing cycles. The system continuously monitors, validates, and processes transactions as they are generated, ensuring that useful action is performed without interruption or down time, thereby achieving both high productivity and zero loss of time.

Inventive Principle:
Principle #20Continuity of useful action

4Reliability

If legacy systems are maintained, then existing operations can continue, but migration risk and consolidation difficulty increase

Engineering Contradiction:
Improveoperational continuityVSAvoidsystem consolidation difficulty
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces a unified transaction processing platform that acts as an intermediary between legacy systems and new processing requirements. This intermediary system can ingest data from and interface with legacy systems while processing transactions through the new unified architecture, enabling gradual migration and consolidation that reduces risk and simplifies the transition process.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent enables preliminary actions and phased migration strategies where the unified system can be prepared and configured in advance to handle transactions from legacy systems. By performing preliminary setup, testing, and configuration before full migration, the system reduces migration risk and makes consolidation more manageable, allowing operational continuity during the transition.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS7783549B1Transaction processing system and method
Publication Date: 2010.08.24 FIDELITY INFORMATION SERVICES LLC
  • US7783549B1 patent drawing
  • US7783549B1 patent drawing
  • US7783549B1 patent drawing

AI summary

A system for processing securities transactions includes a client module to obtain transaction data corresponding to a plurality of heterogeneous financial products from at least one external operational system, a transaction engine that processes the transaction data from the client module to convert and normalize the transaction data, and stores the converted transaction data as a series of temporal events in a transaction database, and a data access module to provide access to the converted transaction data stored in the transaction database.