System and method for implementing transaction processing ecosystems

An embodiment of the present invention is directed to financial transaction ecosystems. A transaction processing ecosystem comprises: a plurality of data sources; a capture interface; and a financial transaction processing system comprising a message bus and a plurality of processors interfacing with the message bus and configured to perform: receiving, via the capture interface, raw data for a payment transaction, wherein the raw data comprises client instructions; normalizing, via the capture interface, the raw data into a normalized transaction format based on a standard data model; publishing, via the capture interface, the normalized transaction format to a message bus; processing, via a first processor of the plurality of processors, the normalized transaction format; and completing the transaction.

FIELD OF THE INVENTION

The present disclosure generally relates to a transaction processing ecosystem based on an event driven architecture.

BACKGROUND OF THE INVENTION

Currently, financial institutions use thousands of systems to process transactions. However, many systems perform redundant features and often duplicate high-level functionality many times over. These systems do not provide a full set of end-to-end technical and business functionality leveraging standard accounting practices or providing consistency from a data perspective.

For example,FIG.1, which depicts a block diagram of a conventional cash management platform for a financial institution, includes a number redundant system components, such as entitlement verification, booking, archiving, etc. With such conventional systems, product offering is not unified nor in real-time and reporting is inconsistent and centered on products, not clients.

SUMMARY OF THE INVENTION

According to one embodiment, the invention relates to a transaction processing ecosystem that comprises: a plurality of data sources; a capture interface; and a financial transaction processing system comprising a message bus and a plurality of processors interfacing with the message bus and configured to perform: receiving, via the capture interface, raw data for a payment transaction, wherein the raw data comprises client instructions; normalizing, via the capture interface, the raw data into a normalized transaction format based on a standard data model; publishing, via the capture interface, the normalized transaction format to a message bus; processing, via a first processor of the plurality of processors, the normalized transaction format; and completing the transaction.

According to one embodiment, the invention relates to a method for processing transactions in a transaction processing ecosystem comprising a financial transaction processing system comprising a message bus and a plurality of processors interfacing with the message bus. The method comprises the steps of: receiving, via a capture interface, raw data for a payment transaction, wherein the raw data comprises client instructions; normalizing, via the capture interface, the raw data into a normalized transaction format based on a standard data model; publishing, via the capture interface, the normalized transaction format to a message bus; processing, via a first processor of the plurality of processors, the normalized transaction format; and completing the transaction.

The computer implemented system and method described herein provide unique advantages to entities, organizations and other users, according to various embodiments of the invention. An embodiment of the present invention is directed to financial transaction processing system that provides a full stack end-to-end transaction processing where various functions are tied together through an event driven architecture. An embodiment of the present invention consolidates various processing components into a single platform through an integrated functional-based architecture based on standardized data models. An embodiment of the present invention achieves efficiencies by eliminating duplicate functions and features throughout isolated systems that process financial transactions. The innovative system and method provide reusability capabilities, maximizes scalability (to address volume constraints), improved stability (globally consistent platform), near real-time data, improved regulatory controls and reporting (via booking principles), resource efficiencies and substantial cost savings. These and other advantages will be described more fully in the following detailed description.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following description is intended to convey an understanding of the present invention by providing specific embodiments and details. It is understood, however, that the present invention is not limited to these specific embodiments and details, which are exemplary only. It is further understood that one possessing ordinary skill in the art, in light of known systems and methods, would appreciate the use of the invention for its intended purposes and benefits in any number of alternative embodiments, depending upon specific design and other needs.

The disclosure of U.S. Provisional Patent Application Ser. No. 62/677,882, filed May 30, 2018, is hereby incorporated by reference in its entirety.

An embodiment of the present invention is directed to financial transaction ecosystems. According to an embodiment of the present invention, a financial transaction ecosystem may be based on standard accounting principles and may provide end-to-end transaction processing that may include many functions, such as data capture, transaction booking, asset movement, asset journals/holdings, etc. These functions may be tied together through an event-driven architecture that may be based on one or more standard data models.

FIG.2depicts a financial transaction ecosystem, according to an embodiment of the present invention. As shown inFIG.2, booking engines210, asset movement engine220, and asset record engine230may communicate with each other. An exemplary illustration may include a plurality of booking engines, a single asset movement engine and a single asset record engine. Other variations may be realized.

For example, booking engines210may book transactions, realignments, foreign exchanges, etc. These events may trigger the setup and/or creation of pending journals and positions.

Asset movement engine220may generate and/or monitor events that trigger the takedown/movement of the pending positions to settled and/or confirmed positions.

Asset record engine230may create and/or produce journals and holdings.

By ensuring integrity and following standard principles, the core data may be accurate, timely and linked. Accordingly, an embodiment of the present invention provides scalability, significantly reduced reconciliation breaks and a full event based architecture.

FIG.3depicts an exemplary block diagram of a financial transaction ecosystem, according to an embodiment of the present invention. Ecosystem300may include financial transaction processing system310, which may further include a number of processing components that may be used to conduct, record and/or otherwise be involved in a transaction. For example, financial transaction processing system310may include entitlements module312, moving module314, booking module316, holdings module318, reference data320, notifications module322, data storage module324, and reporting module326. The inclusion of these modules is exemplary only; it should be recognized that fewer, different, or additional modules may be provided as is necessary and/or desired.

According to an embodiment of the present invention, one or more of the modules (e.g.,312,314,316,318,320,322,324,326, etc.) may relate to a plurality of transaction types that may be undertaken by ecosystem300. Thus, not all modules may be involved in all transactions. For example, if a transaction does not require a module, the module may remain idle while monitoring message bus330. In the context of the various embodiments of the present invention, modules may represent processors, processing components, software implementation on hardware components and/or other implementations.

System300may consolidate several modules into a single platform, thereby moving from the conventional vertical silos to an integrated functional-based architecture. Technical advantages may include, for example, technical and operations cost reductions by leveraging common components and code base; consolidated product offerings (e.g., integrated receivables, integrated payables, etc.); a modern, event-based architecture with standardized data model; the use of real-time, or near real-time data; tighter regulatory controls and reporting (via booking principals); and improved stability and scalability.

Each module (e.g.,312,314,316,318,320,322,324,326, etc.) may communicate with message bus330. For example, an event may be written to message bus330, and each module may monitor message bus for an action to take. Once the action is taken, another module may take action.

According to an embodiment of the present invention, the modules (e.g.,312,314,316,318,320,322,324,326, etc.) may be independent (e.g., other than dependencies, they operate independently of each other), and may leverage standard data modules to interface with message bus230. Each module (e.g.,312,314,316,318,320,322,324,326, etc.) may have its own datastore and memory and perform various processing.

According to an embodiment of the present invention, user interfaces340may allow a user to interact with financial transaction processing system310. Exemplary user interfaces340may include, for example, an external client sending a payments file; an external client uploading invoices; an internal or external system sending transactions for securities processing.

According to an embodiment of the present invention, storage350may be provided. Storage350may include, for example cache storage (e.g., Gemfire, Hazelcast, etc.), in-memory datastore, persistent storage with cache, etc. For example, system300may persist every transaction on the bus to a long term datastore.

FIG.4depicts an exemplary asset record system, according to an embodiment of the present invention. As shown inFIG.4, an exemplary cash management system may include a transaction processing system. System400may include capture module430, that may capture raw data from, for example, systems such as payables440(including check services442, digital payables444), receivables450(including receivables management452), deposits460(including cash balance management462), etc. Capture module430may capture raw data from these and other systems in any format, and may convert the raw data to a normalized format (e.g., a logical data model format, discussed below).

According to an embodiment of the present invention, raw data from escrow system470, including escrow management472, may be received by financial transaction processing system310.

Financial transaction processing system310may include modules, such as booking module316, movement module314, holding module318, notifications module322, messaging module323, reference data320, data storage module324, and reporting module326. Other modules may be provided as is necessary and/or desired. Each module may register with message bus330for the transactions types that it may process.

Utilities480may interact with financial transaction processing system310. Utilities480may include modules, for example, pricing482, sanctions484, billing486, and statements488. For example, utilities480may provide general service(s) that may be used by multiple functional engines (e.g., inputs) as parameters may be provided by any component. In this example, an output may include an answer or output data and may then be used for further processing.

Client tools490may include client services492and client facing tools494. For example, client tools may provide a user interface for reporting, auditing, etc. For example, client tools490may enable clients to query pervious transactions, initiate transactions, etc.

FIG.5depicts an architectural diagram of a financial transaction ecosystem, according to an embodiment of the present invention.FIG.5illustrates an exemplary asset record system. For example, system500may include data caching module530, which may cache information (e.g., journal information, caching information, etc.).

According to an embodiment of the present invention, System500may further include a plurality of modules (e.g., module520, module522, and module524, etc.) that may interact with message bus330. Although three modules are depicted, a greater or fewer number may be provided as is necessary and/or desired.

According to an embodiment of the present invention, the modules may represent consumers of the message bus that may also create new LDM objects and publish them back to message bus.

Modules520,522, and524may include, for example, an asset movement module, a trade booking module, a journal module, aggregation module, ladders module, reinstatement module, etc. Other modules may be provided as is necessary and/or desired.

System500may also include a plurality of writers540,542, and544. Although three writers are depicted, a greater or fewer number may be provided as is necessary and/or desired. Writers440,442,444may include, for example, a journal writer, a holding writer, etc.

According to an embodiment of the present invention, a user interface may be provided that permits view of objects on the message bus. Request/Response may allow consumers to make calls for holding (position) lookups that have already been published to the bus and stored in a database. For example, Request/Response may represent a convenience feature so that consumers who want the information may make ad hoc calls rather than listening to all published positions on the bus.

System500may further include asset record database550that may maintain a record of transactions, assets, etc. According to an embodiment of the present invention, asset record database550may service Request/Response calls as well as be used as a permanent store for purposes of loading real time caches for resiliency purposes. According to an embodiment of the present invention, real time caches may be repopulated based on asset record database following downtime or maintenance.

FIG.6depicts a method for transaction processing in a financial transaction processing ecosystem, according to an embodiment of the present invention. At step610, raw data may be captured. At step615, the raw data may be normalized. At step620, the normalized transaction may be published to a message bus. At step625, modules and/or functions in the transaction processing ecosystem may monitor or listen to the message bus. At step630, transactions may be processed. At step635, transaction processing may be completed and/or forwarded to another system. While the process ofFIG.6illustrates certain steps performed in a particular order, it should be understood that the embodiments of the present invention may be practiced by adding one or more steps to the processes, omitting steps within the processes and/or altering the order in which one or more steps are performed. Additional details for each step are provided below.

At step610, raw data may be captured and brought into the processing ecosystem using, for example, a capture function. Examples of raw data may include individual or batches of transactions, files, etc. For example, the raw data may be received from user interfaces and/or systems. In addition, the raw data may be received in various formats.

At step615, the raw data may be normalized. This may involve converting raw data to a normalized transformation format. According to an embodiment of the present invention, a configuration file (or a “config” file) may store a mapping of registered raw data formats to a standard format, such as a LDM (Logical Data Model) format.

For example, the raw data may be run through one or more processes to convert the raw data into standardized or normalized transactions that may be published to a message bus. According to an embodiment of the present invention, the transactions may be in an approved LDM (Logical Data Model) format. For example, each raw data format may be registered during a registration process, and the data fields in the raw data format may be mapped to an appropriate field in the LDM format.

According to an embodiment of the present invention, the configuration file may further identify modules that are involved in processing the transaction. For example, the LDM may be transformed into any suitable format, such as protobuf, JSON, XML, etc.

An illustrative example of a cash transaction in LDM format is provided below:

An illustrative example of a payment transaction in LDM format is provided below:

At step620, the normalized transaction may be published to a message bus.

At step625, modules and/or functions in the transaction processing ecosystem may monitor and/or listen to the message bus, and, at step630, may process relevant normalized transactions. For example, at start up or at any other appropriate time, each module may register with the message bus (or a message bus controller) with the types of transactions that the module is responsible for processing, order of processing, etc. When such a transaction is published to the message bus, one or more modules may “pick up” the transaction from the message bus and perform processing on the transaction. When the module picks up the transaction, it may publish an acknowledgement message to the message bus informing other modules of the state of the transaction.

According to an embodiment of the present invention, rather than the module picking up the transaction from the message bus, the message bus may push a transaction to a module based on the registration information for the module.

For example, financial transactions may be identified and “picked up” by a booking module, which may then prepare the transaction for processing. There may be multiple types of booking modules depending on the transaction. Examples include cash, securities, billing, invoice, expected cash receipt, billing invoice transaction, remittance, etc. According to an embodiment of the present invention, the booking module may create multiple “legs” for a single transaction for different legal entities. The module may then publish one more bookable transactions to the message bus.

An asset movement module and an asset record module may listen for bookable transactions that are published to the message bus. The asset movement module may pick up the bookable transaction(s) and create a settlement transaction having an initial state of “open.” This function may further deliver the settlement transaction to the appropriate settlement module (e.g., CHiP, FED, SWIFT, etc.). As transactions are settled, an asset movement module may update the state of the settlement transaction to closed, complete, etc.

According to an embodiment of the present invention, a standard reference data cache that identifies the different functions on the bus may call out to/for reference data. According to an exemplary illustration, only identifiers may be stored on the transactions that flow through the ecosystem and the reference data cache may be called if those identifiers need to be resolved to obtain the actual or underlying data.

Reference Data may include data relating to Client, Accounts and Counterparty/Third Party (Cpty), Standing Settlement Instructions (SSI), Products, Client preferences and profiles, Clearing data, Market Data, Client Direct Debit (DD) Mandate. Reference data may be stored and managed via a Reference Data Cache Tool. Reference data may further include parties and accounts, products and instruments, escrow deal management (e.g., reference data to manage escrow deals), pricing deal management (e.g., reference data to manage pricing deals for various products and clients), settlement instructions (e.g., client standing instructions), sanctions, billing, statements composition, etc.

According to an embodiment of the present invention, an asset record module may also listen for bookable transactions along with any settlements that have been published to the message bus. The asset record module may include a rules engine that may apply rules against the different bookable transactions to create a journal or record (including, for example, deposit/credit sets), which may also be published to the message bus. The journals may be aggregated into sets and/or other format.

According to an embodiment of the present invention, transactions, including state changes, may be stored in, for example, a data warehouse for reporting and auditing.

At step635, the module may return the processed transaction to the message bus. If the module is the end point for the transaction, the processed transaction may be sent to another system, to a user interface, or may take any other action as is necessary and/or desired.

FIGS.7A and7Bdepict an illustrative example of a payment receipt/pay cash flow, according to an embodiment of the present invention. During pre-capture, “payment.raw”701is transformed to “payment.initiation”702, which may be subsequently enriched/validated through payment capture722. “Payment.norm”704is produced from payment capture722, which results in a “cashtxn.bookable”706from payment booking engine724. “Cashtxn.bookable”707is processed through the asset movement engine726(open settlements) and asset record744(pending journals are created). The payment is confirmed/settled via asset movement engine726which results in “settlement movements”711being settled and asset record744consuming these to pending “positions/journals to settled/confirmed” as represented by708,709,712and713.

As shown inFIG.7A, a new payment or receipt may be initiated by a client or clearing system, as represented by701. Ingestion Channels730may represent a payment initiation source, e.g., client, clearing systems, etc. The data may be received as raw data701at Pre-Capture720, which may represent an Isolation Layer. Pre-Capture720may perform functions, including Transformation, Duplicate Check, Setting of References (Set Ref), and Integration. Payment may be initiated at702from Pre Capture720to Messaging Bus728. Payment capture722may receive payment initiation at703. Through Payment Capture722, payment initiation may be normalized as Payment.Norm at704.

Payment capture722may include various features and functions including Qualification, Except/Repair, Payment Control, Client Batch/Bulk/Aggregation, Fees/Charges/Calculations; Optimize—based on Time and/or Cost; Optimize—Client; Warehouse/Scheduling, FX Booking, Filter Service and Prioritization. Payment capture722may receive data from Standing Orders732. For example, Payment capture722may capture client instructions across various transaction types and further transform into normalized data model. Payment capture722may perform transformation from client specific data model into a universal (or entity specific) data model. The normalized transactional data model message may be published to Messaging Bus728. Capture processing may include OCR/ICR, machine learning, file processing and message processing.

Payment.Norm may be received by Booking Engine724at705to generate a client booking as Cash.Txn.Bookable at706. Booking Engine724may include various features and functions including Transaction Enrichment, Holding Type Derivative, Leg Generation, and Fees/Charges. Leg Generation may represent transactional leg generation, e.g., additional transactions that may be required. Booking Engine724may communicate with Leg Generation734. An embodiment of the present invention may include a plurality of booking engines, e.g., one booking engine for each transaction type. For example, booking engines may share underlying technical components but run as separate instances for different transactional types.

This may be received by Asset Movement726to update Settlement Mission status to Matched at707. Settlement mission may be generated from a settlement file, as shown by SM.Open708, SM.Open.BulkNet708.a, SM.Open.ClearNet708.band SM.Settled711. For example, Settlement Mission status may be OPEN.Matched. Upon settlement, status may be set to SETTLED, via711.

Asset Movement726may include various features and functions including Gateway, Client Bulk Aggregation/Netting, Clearing Netting/Aggregation, Manual Match, Linkage, Approvals, Clearing and Settlement (SM), Auto Settlement, Fails Marking, Credit Check, Exception Management, Payment Controls, and Filter Service. Asset Movement726may receive data (e.g., ddi.norm) from Payment Capture722and further send data (e.g., ddi.norm) to Direct Debit (DD) Management736, e.g., setting up and/or managing client direct debit instructions. Asset Movement726may create settlement missions for various types of transactions that require asset movements. In addition, Asset Movement726may provide a receipt or confirmation message to Ingestion Channels730.

As shown inFIG.7B, payment instruction/collection709may be sent from Payment Channels740to Clearing System742. After the payment has been settled, Settlement710may be returned to Payment Channels740. Journal (posting) may be created for both client and settlement. Journal/Holding status may be represented as Pending-Post.

Asset Record744may create journals and holdings from input events. For example, Asset Record744may include Rules Engine, Journal Engine and Holding Engine. Rules Engine may hold rules for transformation of events into journals. Journal Engine may create journals (DR/CR sets) from events. For example, Holding Engine may aggregate DR/CR sets that have been produced and create holdings (e.g., positions, balances). Other engines may include an Aggregation Engine that aggregates journal sets and applies impacts to Holdings and a Publish Engine may publish Journals and Holdings as changes occur to each. Also, Asset Record744may post account journal for both client and settlement. Through the interactions of707,708,709,711,712and713, Journal/Holding status may be represented as Settled-Post. Data may be posted to a General Ledger746as well as a Data Warehouse748. Data may include Payment.Init; Payment.Norm; Cash.Txn; SM.Open; TD.Journal; TS.Holdings. SM.Settled, SD.Journal and SD.Holding as represented by716.

An embodiment of the present invention may be applied to various applications, businesses, etc. For example, the event based infrastructure may be applied to core banking technologies, merchant services businesses, international fixed income businesses, etc. In addition, various extensions may be applied. For example, the financial transaction processing system may support exception management and reconciliation features. For example, exceptions may apply to trade booking engines, settlement systems as well as other systems of record. If an exception is closed in one system of record, an embodiment of the present invention may cascade or route the update through the messaging bus and thereby remove any duplicative effort relating to the exception. The exception may be read by a reconciliation system of record or task management system of record, as appropriate. This results in improved consistency and uniformity of data and response.

An embodiment of the present invention may support a position rollup and/or position aggregate. For example, a business may request information on an available balance, which may be an aggregate of underlying balances and positions. This may be relevant to virtual accounts where a member may have an account and reside in a certain region. The funding for the region may be at an aggregate level where the aggregate needs funding. Accordingly, an embodiment of the present invention may support position checks at the aggregate level before transactions can be allowed to hit the underlying balance. Another example may involve an entity having to pay developers in a region or currency. Other aggregates may depend on specific use case scenarios. For example, for a loan, a business may want to calculate available positions or available balances that would exclude an amount of the loan. Accordingly, an embodiment of the present invention may be configurable based on the business rules to determine aggregate level positions.

The processing machine used to implement the invention may utilize a suitable operating system. Thus, embodiments of the invention may include a processing machine running the iOS operating system, the OS X operating system, the Android operating system, the Microsoft Windows™ operating system, the Unix operating system, the Linux operating system, the Xenix operating system, the IBM AIX™ operating system, the Hewlett-Packard UX™ operating system, the Novell Netware™ operating system, the Sun Microsystems Solaris™ operating system, the OS/2™ operating system, the BeOS™ operating system, the Macintosh operating system, the Apache operating system, an OpenStep™ operating system or another operating system or platform.