System and method for implementing a transaction processing ecosystem

Abstract

Embodiments of the present invention relate to a financial transaction ecosystem. The transaction processing ecosystem includes: multiple data sources; a capture interface and a financial transaction processing system, the financial transaction processing system includes a message bus and multiple processors connected to the message bus, and the multiple processors are configured to perform the following operations: receiving raw data for a payment transaction via the capture interface, wherein the raw data includes a customer instruction; normalizing the raw data into a normalized transaction format based on a standard data model via the capture interface; publishing the normalized transaction format to the message bus via the capture interface; processing the normalized transaction format via a first processor among the multiple processors; and completing the transaction.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 62 / 731,396, filed on September 14, 2018, the entire contents of which are incorporated herein in their entirety. Technical Field

[0003] The present disclosure generally relates to a transaction processing ecosystem based on an event-driven architecture. Background Art

[0004] Currently, financial institutions use thousands of systems to process transactions. However, many systems perform redundant functions and often duplicate high-level functions multiple times. These systems do not provide a full set of end-to-end technical and business capabilities that leverage standard accounting practices or provide consistency from a data perspective.

[0005] For example, Figure 1 depicts a block diagram of a conventional cash management platform for a financial institution, which includes many redundant system components, such as entitlement verification, booking, archiving, etc. With such a conventional system, product offerings are neither uniform nor real-time, and reporting is inconsistent and focused on products rather than customers. Summary of the invention

[0006] According to one embodiment, the present invention relates to a transaction processing ecosystem, which includes: multiple data sources; a capture interface; and a financial transaction processing system, the financial transaction processing system including a message bus and multiple processors connected to the message bus, the multiple processors being configured to perform the following operations: receiving raw data for a payment transaction via the capture interface, wherein the raw data includes customer instructions; normalizing the raw data into a normalized transaction format based on a standard data model via the capture interface; publishing the normalized transaction format to the message bus via the capture interface; processing the normalized transaction format via a first processor among the multiple processors; and completing the transaction.

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

[0008] According to various embodiments of the present invention, the computer-implemented systems and methods described herein provide unique advantages for entities, organizations, and other users. Embodiments of the present invention relate to a financial transaction processing system that provides full stack end-to-end transaction processing, in which various functions are bound together through an event-driven architecture. Embodiments of the present invention integrate various processing components into a single platform through an integrated function-based architecture based on a standardized data model. Embodiments of the present invention achieve efficiency by eliminating duplicate functions and features in isolated systems that process financial transactions. Innovative systems and methods provide reusability capabilities, maximize scalability (to address capacity constraints), improve stability (globally consistent platform), near real-time data, improve regulatory control and reporting (through subscription principles), improve resource efficiency, and save considerable costs. These and other advantages will be more fully described in the detailed description below. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to facilitate a more complete understanding of the present invention, reference is now made to the accompanying drawings which should not be construed as limiting the present invention but are merely intended to illustrate various aspects and embodiments of the present invention.

[0010] Figure 1 depicts an overview of a conventional cash management platform.

[0011] Figure 2 A financial transaction ecosystem according to an embodiment of the present invention is depicted.

[0012] Figure 3 An exemplary cash management system including a transaction processing system according to an embodiment of the present invention is depicted.

[0013] Figure 4 An exemplary asset recording system according to an embodiment of the present invention is depicted.

[0014] Figure 5 An architectural diagram of a financial transaction ecosystem according to an embodiment of the present invention is depicted.

[0015] Figure 6 A method for transaction processing in a financial transaction processing ecosystem according to an embodiment of the present invention is described.

[0016] Fig. 7A and Figure 7B An illustrative example of a payment receipt / payment cash flow according to an embodiment of the present invention is depicted. DETAILED DESCRIPTION

[0017] The following description is intended to convey an understanding of the present invention by providing specific embodiments and details. However, it should be understood that the present invention is not limited to these exemplary embodiments and details. It should also be understood that, based on known systems and methods, a person of ordinary skill in the art will use the present invention for its intended purpose and benefit in any number of alternative embodiments according to specific designs and other needs.

[0018] The disclosure of U.S. Provisional Patent Application Serial No. 62 / 677,882, filed on May 30, 2018, is incorporated herein by reference in its entirety.

[0019] Embodiments of the present invention relate to a financial transaction ecosystem. According to embodiments of the present invention, the financial transaction ecosystem may be based on standard accounting principles and may provide end-to-end transaction processing, which may include many functions such as data capture, transaction booking, asset movement, asset journal / holding, etc. These functions may be tied together through an event-driven architecture, which may be based on one or more standard data models.

[0020] Figure 2 A financial transaction ecosystem according to an embodiment of the present invention is described. Figure 2 As shown, booking engine 210, asset movement engine 220, and asset record engine 230 can communicate with each other. An exemplary illustration may include multiple booking engines, a single asset movement engine, and a single asset record engine. Other variations may be implemented.

[0021] For example, the booking engine 210 may book transactions, rescheduling, foreign exchange conversions, etc. These events may trigger the establishment and / or creation of open journals and positions.

[0022] The asset movement engine 220 may generate and / or monitor events that trigger the removal / movement of open positions to settled and / or confirmed positions.

[0023] The asset recording engine 230 may create and / or generate journals and holdings.

[0024] By ensuring integrity and following standard principles, core data can be accurate, timely and linked.Thus, embodiments of the present invention provide scalability, significantly reduced reconciliation interruptions, and a complete event-based architecture.

[0025] Figure 3An exemplary block diagram of a financial transaction ecosystem according to an embodiment of the present invention is depicted. Ecosystem 300 may include a financial transaction processing system 310, which may further include a plurality of processing components that may be used to conduct, record, and / or otherwise participate in transactions. For example, financial transaction processing system 310 may include an entitlement module 312, a movement module 314, a reservation module 316, a holding module 318, reference data 320, a notification module 322, a data storage module 324, and a reporting module 326. These modules are included only as examples; it should be appreciated that fewer, different, or additional modules may be provided as needed and / or desired.

[0026] According to embodiments of the invention, one or more of the modules (e.g., 312, 314, 316, 318, 320, 322, 324, 326, etc.) may be involved in multiple transaction types that may be undertaken by the ecosystem 300. Thus, not all modules may participate in all transactions. For example, if a module is not required for a transaction, the module may remain idle while monitoring the message bus 330. In the context of various embodiments of the invention, a module may represent a software implementation on a processor, a processing component, a hardware component, and / or other implementations.

[0027] System 300 can consolidate several modules into a single platform, thereby moving from conventional vertical silos to an architecture based on integrated functionality. Technical advantages may include, for example, reduced technology and operating costs by leveraging common components and code bases; integrated product offerings (e.g., integrated receivables, integrated payables, etc.); a modern event-based architecture with standardized data models; use of real-time or near real-time data; tighter regulatory controls and reporting (through booking leaders); and improved stability and scalability.

[0028] Each module (e.g., 312, 314, 316, 318, 320, 322, 324, 326, etc.) can communicate with a message bus 330. For example, an event can be written to the message bus 330, and each module can monitor the message bus to see what action to take. Once an action is taken, another module can take action.

[0029] According to an embodiment of the present invention, modules (e.g., 312, 314, 316, 318, 320, 322, 324, 326, etc.) may be independent (e.g., unlike dependencies, they operate independently of each other) and may utilize standard data modules to interface with the message bus 330. Each module (e.g., 312, 314, 316, 318, 320, 322, 324, 326, etc.) may have its own data storage area and memory and may perform various processes.

[0030] According to an embodiment of the present invention, user interface 340 may allow a user to interact with financial transaction processing system 310. Exemplary user interfaces 340 may include, for example, an external client sending a payment document; an external client uploading an invoice; an internal or external system sending a transaction for securities processing.

[0031] According to an embodiment of the present invention, a memory 350 may be provided. The memory 350 may include, for example, a cache memory (e.g., Gemfire, Hazelcast, etc.), an in-memory data storage area, a persistent memory with a cache, etc. For example, the system 300 may persist each transaction on the bus to a long-term data storage area.

[0032] Figure 4 An exemplary asset recording system according to an embodiment of the present invention is depicted. Figure 4 As shown, an exemplary cash management system may include a transaction processing system. System 400 may include a capture module 430, which may capture raw data, for example, from systems such as accounts payable 440 (including check services 442, digital accounts payable 444), accounts receivable 450 (including accounts receivable management 452), deposits 460 (including cash balance management 462), etc. Capture module 430 may capture raw data from these systems and other systems in any format, and may convert the raw data into a normalized format (e.g., the logical data model format discussed below).

[0033] According to an embodiment of the present invention, the financial transaction processing system 310 may receive raw data from the escrow system 470 (including the escrow management 472).

[0034] The financial transaction processing system 310 may include modules such as a subscription module 316, a move module 314, a holding module 318, a notification module 322, a messaging module 323, reference data 320, a data storage module 324, and a reporting module 326. Other modules may be provided as needed and / or desired. Each module may register with the message bus 330 the transaction type it can process.

[0035] Utilities 480 can interact with financial transaction processing system 310. Utilities 480 can include modules such as pricing 482, sanctions / penalties 484, billing 486, and reporting 488. For example, utilities 480 can provide a general service that can be used by multiple functional engines (e.g., inputs) because any component can provide parameters. In this example, the output can include a response or output data, which can then be used for further processing.

[0036] Client tools 490 may include client services 492 and client-facing tools 494. For example, client tools may provide a user interface for reporting, auditing, etc. For example, client tools 490 may enable clients to query previous transactions, initiate transactions, etc.

[0037] Figure 5 An architectural diagram of a financial transaction ecosystem according to an embodiment of the present invention is depicted. Figure 5 An exemplary asset recording system is illustrated.For example, system 500 can include a data cache module 530 that can cache information (eg, journal information, cache information, etc.).

[0038] According to an embodiment of the present invention, system 500 may further include multiple modules (e.g., module 520, module 522, module 524, etc.) that may interact with message bus 330. Although three modules are described, more or less may be provided as needed and / or desired.

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

[0040] Modules 520, 522, and 524 may include, for example, an asset movement module, a trade booking module, a journal module, an aggregation module, a ladder module, a recovery module, etc. Other modules may be provided as needed and / or desired.

[0041] The system 500 may also include a plurality of writers 540, 542, and 544. Although three writers are depicted, a greater or lesser number may be provided as needed and / or desired. The writers 540, 542, 544 may include, for example, a journal writer, a holding writer, and the like.

[0042] According to an embodiment of the present invention, a user interface can be provided that allows viewing of objects on the message bus. Request / response can allow a consumer to call a hold (position / position) lookup that has been published to the bus and stored in a database. For example, request / response can represent a convenience feature so that a consumer who wants information can make an ad hoc call instead of listening to all published positions on the bus.

[0043] The system 500 may further include an asset record database 550, which may maintain records of transactions, assets, etc. According to an embodiment of the present invention, the asset record database 550 may serve request / response calls as well as serve as permanent storage for loading the real-time cache for resiliency purposes. According to an embodiment of the present invention, the real-time cache may be repopulated based on the asset record database after an outage or maintenance.

[0044] Figure 6 A method for performing transaction processing in a financial transaction processing ecosystem according to an embodiment of the present invention is depicted. At step 610, raw data can be captured. At step 615, the raw data can be normalized. At step 620, the normalized transaction can be published to a message bus. At step 625, modules and / or functions in the transaction processing ecosystem can monitor or listen to the message bus. At step 630, the transaction can be processed. At step 635, the transaction processing can be completed and / or forwarded to another system. Although Figure 6 The process of the present invention describes certain steps performed in a specific order, but it should be understood that embodiments of the present invention can be practiced by adding one or more steps to the process, omitting steps within the process, and / or changing the order in which one or more steps are performed. Additional details of each step are provided below.

[0045] At step 610, raw data may be captured using, for example, a capture function and introduced into a processing ecosystem. Examples of raw data may include individual or batch transactions, files, and the like. For example, raw data may be received from a user interface and / or a system. Additionally, raw data may be received in a variety of formats.

[0046] At step 615, the raw data may be normalized. This may involve converting the raw data into a normalized transformed format. According to an embodiment of the present invention, a configuration file (or "config" file) may store a mapping of registered raw data formats to a standard format (e.g., an LDM (Logical Data Model) format).

[0047] 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 in a registration process, and data fields in the raw data format may be mapped to appropriate fields in the LDM format.

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

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

[0050] cashTransaction{

[0051]

[0052]

[0053]

[0054]

[0055]

[0056]

[0057]

[0058]

[0059]

[0060]

[0061]

[0062]

[0063] At step 620, the normalized transaction may be published to a message bus.

[0064] At step 625, modules and / or functions in the transaction processing ecosystem may monitor and / or listen to the message bus, and at step 630, may process the relevant normalized transactions. For example, at startup or at any other suitable time, each module may register with the message bus (or message bus controller) the transaction types, processing order, etc. that the module is responsible for processing. When such transactions are posted to the message bus, one or more modules may "pick up" the transactions from the message bus and perform processing on the transactions. When a module picks up a transaction, it may publish a confirmation message to the message bus to notify other modules of the transaction status.

[0065] According to an embodiment of the present invention, instead of the module picking up the transaction from the message bus, the message bus can push the transaction to the module based on the registration information of the module.

[0066] For example, a financial transaction may be identified and "picked up" by a booking module, which may then prepare the transaction for processing. Depending on the transaction, there may be multiple types of booking modules. Examples include cash, securities, bills, invoices, expected cash receipts, bill invoice transactions, remittances, etc. According to an embodiment of the present invention, a booking module may create multiple "branches" for a single transaction for different legal entities. The module may then publish another bookable transaction to the message bus.

[0067] The asset movement module and the asset recording module can listen to bookable transactions published to the message bus. The asset movement module can pick up (one or more) bookable transactions and create a settlement transaction with an initial status of "open". This function can further pass the settlement transaction to the appropriate settlement module (e.g., CHiP, FED, SWIFT, etc.). As the transaction is settled, the asset movement module can update the status of the settlement transaction to cleared, completed, etc.

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

[0069] Reference data may include data related to "Client", "Accounts and Counterparties / Third Parties (Cpty)", "Standing Settlement Instructions" (SSI), "Products", "Customer Preferences and Profiles", "Clearing Data", "Market Data", "Customer Direct Debit (DD) Authorizations". Reference data may be stored and managed through a reference data cache tool. Reference data may further include parties and accounts, products and instruments, managed transaction management (e.g., reference data for managing managed transactions), priced transaction management (e.g., reference data for managing priced transactions for various products and customers), settlement instructions (e.g., customer standing instructions), sanctions / penalties, billing, report composition, etc.

[0070] According to an embodiment of the present invention, the asset record module can also listen to the bookable transactions and any settlements that have been made. The asset record module can include a rule engine that can apply rules to different bookable transactions to create journals or records (including, for example, deposit / credit sets), which can also be published to the message bus. The journals can be aggregated into collections and / or other formats.

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

[0072] The module may return the processed transaction to the message bus at step 635. If the module is an endpoint for the transaction, the processed transaction may be sent to another system, to a user interface, or any other action may be taken as needed and / or desired.

[0073] Fig. 7A and Figure 7BAn illustrative example of a payment receipt / payment cash flow according to an embodiment of the present invention is depicted. During pre-capture, "payment.raw" 701 is converted to "payment.initiation" 702, which can then be enriched / validated by payment capture 722. "Payment.norm" 704 is generated from payment capture 722, the result of which is "cashtxn.bookable" 706 from payment booking engine 724. "Cashtxn.bookable" 707 is processed by asset movement engine 726 (open clearing) and asset record 744 (creating pending journal). Payments are confirmed / settled via asset movement engine 726, which causes "settlement movement" 711 to be settled, and asset record 744 consumes these to outstanding "positions / journals to be settled / confirmed", as shown at 708, 709, 712 and 713.

[0074] like Fig. 7A As shown, a new payment or receipt can be initiated by a client or a clearing system, as shown at 701. Intake channel 730 can represent the payment origin, such as a client, a clearing system, etc. Data can be received as raw data 701 at pre-capture 720, which can represent an isolation layer. Pre-capture 720 can perform functions including transformation, duplicate checking, reference setting (set reference), and integration. Payment can be initiated from pre-capture 720 to message bus 728 at 702. Payment capture 722 can receive the payment initiation at 703. Through payment capture 722, the payment initiation can be normalized to payment.norm at 704.

[0075] Payment capture 722 may include various features and functions, including eligibility, exceptions / repairs, payment controls, customer batching / bulk / aggregation, fees / charges / calculations; optimization - based on time and / or cost; optimization - customer; warehouse / scheduling, foreign exchange booking, screening services, and prioritization. Payment capture 722 may receive data from regular orders 732. For example, payment capture 722 may capture customer instructions across various transaction types and further convert to a normalized data model. Payment capture 722 may perform a conversion from a customer-specific data model to a generic (or entity-specific) data model. Normalized transaction data model messages may be published to a message bus 728. Capture processing may include OCR / ICR, machine learning, file processing, and message processing.

[0076] Booking engine 724 may receive Payment.norm at 705 to generate a customer booking as Cash.Txn.Bookable at 706. Booking engine 724 may include various features and functions, including transaction enrichment, holding type derivation, branch generation, and fees / charges. Branch generation may represent transaction branch generation, e.g., additional transactions that may be required. Booking engine 724 may communicate with branch generation 734. Embodiments of the present invention may include multiple booking engines, e.g., one booking engine for each transaction type. For example, booking engines may share underlying technology components, but may run as separate instances for different transaction types.

[0077] At 707, asset movement 726 may receive this information to update the settlement task status to matched. A settlement task may be generated from a settlement file, as shown in SM.Open 708, SM.Open.BulkNet 708.a, SM.Open.ClearNet 708.b, and SM.Settled 711. For example, a settlement task status may be "Open.Matched". Once settled, the status may be set to "settled" via 711.

[0078] Asset movement 726 may include various features and functions, including gateway, client bulk aggregation / netting, clearing netting / aggregation, manual matching, linking, approval, clearing and settlement (SM), automatic settlement, failure marking, credit check, exception management, payment control and screening services. Asset movement 726 may receive data (e.g., ddi.norm) from payment capture 722, and further send the data (e.g., ddi.norm) to direct debit (DD) management 736, for example, to set up and / or manage customer direct debit instructions. Asset movement 726 may create settlement tasks for various types of transactions that require asset movement. In addition, asset movement 726 may provide a receipt or confirmation message to intake channel 730.

[0079] like Figure 7B As shown, payment instructions / collections 709 may be sent from payment channel 740 to clearing system 742. After the payment has been settled, settlement 710 may be returned to payment channel 740. Journals (postings) may be created for both the customer and the settlement. The journal / holding status may be indicated as pending posting.

[0080] The asset record 744 can create journals and holdings based on input events. For example, the asset record 744 may include a rule engine, a journal engine, and a holding engine. The rule engine can save the rules for converting events into journals. The journal engine can create journals (DR / CR sets) based on events. For example, the holding engine can aggregate the DR / CR sets that have been generated and create holdings (e.g., positions, balances). Other engines may include an aggregation engine and a publishing engine, which aggregates journal sets and applies the effects to holdings, while the publishing engine can publish journals and holdings when they change. Similarly, the asset record 744 can post account journals for both customers and settlements. Through the interaction of 707, 708, 709, 711, 712, and 713, the journal / holding status can be represented as a settled posting. Data can be posted to the general ledger 746 and the data warehouse 748. The data may include Payment.Init; Payment.Norm; Cash.Txn; SM.Open; TD.Journal; TS.Holdings.SM.Settled, SD.Journal and SD.Holding, as shown in 716.

[0081] Embodiments of the present invention may be applied to a variety of applications, enterprises, and the like. For example, event-based infrastructure may be applied to core banking technology, merchant services enterprises, international fixed income enterprises, and the like. In addition, various extensions may be applied. For example, a financial transaction processing system may support exception management and reconciliation functions. For example, exceptions may apply to transaction booking engines, settlement systems, and other systems of record. If an exception is closed in one system of record, an embodiment of the present invention may cascade or route updates through a messaging bus, thereby eliminating any duplication of efforts associated with the exception. The exception may be read by the reconciliation system of record or the task management system of record, as appropriate. This may improve the consistency and uniformity of data and responses.

[0082] Embodiments of the present invention may support position aggregation and / or position aggregation. For example, a business may request information about an available balance, which may be the sum of a base balance and a position. This may be related to a virtual account where a member may have an account and reside in a region. The funds in the region may be at an aggregation level where the funds are required for aggregation. Therefore, embodiments of the present invention may support position checks at an aggregation level before a transaction can be allowed to reach a base balance. Another example may involve an entity that must pay a developer in a region or currency. Other aggregations may depend on specific use case scenarios. For example, for a loan, a business may want to calculate an available position or available balance that excludes the loan amount. Therefore, embodiments of the present invention may be configured based on business rules to determine aggregation-level positions.

[0083] In the following, general aspects of embodiments of the systems and methods of the present invention will be described.

[0084] The system of the present invention or part of the system of the present invention can be in the form of a "processing machine", such as a general-purpose computer. As used herein, the term "processing machine" should be understood to include at least one processor using at least one memory. At least one memory stores an instruction set. The instructions can be permanently or temporarily stored in one or more memories of the processing machine. The processor executes the instructions stored in the one or more memories to process data. The instruction set can include various instructions for performing one or more specific tasks, such as those tasks described above. Such an instruction set for performing a specific task can be characterized as a program, a software program, or simply software.

[0085] In one embodiment, the processing machine may be a special purpose processor.

[0086] As described above, the processing machine executes instructions stored in one or more memories to process data. Such processing of data may, for example, be in response to commands of one or more users of the processing machine, in response to previous processing, in response to a request from another processing machine, and / or any other input.

[0087] As described above, the processing machine used to implement the present invention can be a general-purpose computer. However, the processing machine can also utilize any of a variety of other technologies, including special-purpose computers, computer systems including, for example, microcomputers, minicomputers or mainframes, programmed microprocessors, microcontrollers, peripheral integrated circuit components, CSIC (customer-specific integrated circuits) or ASICs (application-specific integrated circuits) or other integrated circuits, logic circuits, digital signal processors, programmable logic devices (such as FPGAs, PLDs, PLAs or PALs), or any other device or device arrangement capable of implementing the steps of the process of the present invention.

[0088] The processing machine used to implement the present invention can utilize a suitable operating system. Therefore, embodiments of the present invention may include running an iOS operating system, an OS X operating system, an Android operating system, a Microsoft Windows TM Operating system, Unix operating system, Linux operating system, Xenix operating system, IBM AIX TM Operating system, Hewlett-Packard UX TM Operating system, Novell Netware TM Operating system, Sun Microsystems Solaris TM Operating system, OS / 2 TM Operating system, BeOS TM Operating system, Macintosh operating system, Apache operating system, OpenStep TM Operating system or other operating system or platform processor.

[0089] It should be understood that in order to practice the method of the present invention as described above, the processor and / or memory of the processing machine need not be physically located in the same geographical location. That is, each of the processor and memory used by the processing machine can be located in geographically different locations and connected to communicate in any suitable manner. In addition, it should be understood that each of the processor and / or memory can be composed of different physical equipment. Therefore, the processor does not have to be a single piece of equipment in one location, and the memory is another single piece of equipment in another location. That is, it is expected that the processor can be two pieces of equipment located in two different physical locations. Two different pieces of equipment can be connected in any suitable manner. In addition, the memory can include two or more parts of the memory in two or more physical locations.

[0090] For further explanation, as described above, processing is performed by various components and various memories. However, it should be understood that according to another embodiment of the present invention, as described above, processing performed by two different components can be performed by a single component. In addition, as described above, processing performed by a different component can be performed by two different components. In a similar manner, according to another embodiment of the present invention, as described above, memory storage performed by two different memory portions can be performed by a single memory portion. In addition, as described above, memory storage performed by a different memory portion can be performed by two memory portions.

[0091] In addition, various techniques may be used to provide communications between various processors and / or memories, as well as to allow the processor and / or memory of the present invention to communicate with any other entity; i.e., to obtain further instructions or to access and use remote memory storage. Such techniques for providing such communications may include a network, the Internet, an intranet, an extranet, a local area network, an Ethernet, wireless communications via a cellular tower or satellite, or any client server system that provides communications. Such communications techniques may use any suitable protocol, such as TCP / IP, UDP, or OSI.

[0092] As described above, instruction sets may be used in the processing of the present invention. The instruction set may be in the form of a program or software. The software may be in the form of, for example, system software or application software. The software may also be in the form of, for example, a collection of separate programs, a program module within a larger program, or a portion of a program module. The software used may also include modular programming in the form of object-oriented programming. The software tells the processor how to process the data being processed.

[0093] In addition, it should be understood that the instructions or instruction sets used in the embodiments and operations of the present invention may be in a suitable form so that a processing machine can read the instructions. For example, the instructions forming the program may be in the form of an appropriate programming language, which is converted into a machine language or object code to allow one or more processors to read the instructions. That is, a compiler, assembler, or interpreter is used to convert written lines of programming code or source code in a particular programming language into machine language. Machine language is a binary-coded machine instruction that is specific to a particular type of processing machine (i.e., a particular type of computer, for example). A computer understands machine language.

[0094] According to various embodiments of the present invention, any suitable programming language may be used. Illustratively, the programming language used may include, for example, assembly language, Ada, APL, Basic, C, C++, COBOL, dBase, Forth, Fortran, Java, Modula-2, Pascal, Prolog, REXX, Visual Basic, and / or JavaScript. In addition, it is not necessary to utilize a single type of instruction or a single programming language in conjunction with the operation of the system and method of the present invention. Instead, any number of different programming languages ​​may be utilized as needed and / or desired.

[0095] Likewise, the instructions and / or data used in the practice of the present invention may utilize any compression or encryption techniques or algorithms as desired. Encryption modules may be used to encrypt data. In addition, for example, appropriate decryption modules may be used to decrypt files or other data.

[0096] As described above, the present invention may illustratively be embodied in the form of a processor (including, for example, a computer or computer system) including at least one memory. It should be understood that, as desired, the instruction set (i.e., software, for example) that enables the computer operating system to perform the above operations may be included on any of a variety of one or more media. In addition, the data processed by the instruction set may also be included on any of a variety of one or more media. That is, the specific medium (i.e., the memory in the processor) used to store the instruction set and / or data used in the present invention may, for example, take any of a variety of physical forms or transmissions. Illustratively, the medium may be paper, paper transparency, optical disk, DVD, integrated circuit, hard disk, floppy disk, optical disk, magnetic tape, RAM, ROM, PROM, EPROM, wire, cable, optical fiber, communication channel, satellite transmission, memory card, SIM card or other remote transmission and any other medium or data source that may be read by the processor of the present invention.

[0097] In addition, one or more memories used in a processor implementing the present invention may be in any of a variety of forms to allow the memory to store instructions, data or other information as required. Thus, the memory may be in the form of a database to store data. The database may use any desired file arrangement, such as a flat file arrangement or a relational database arrangement.

[0098] In the system and method of the present invention, various "user interfaces" can be utilized to allow the user to dock with one or more processing machines for realizing the present invention. As used herein, the user interface includes any hardware, software or combination of hardware and software used by the processing machine that the user interacts with the processing machine. The user interface can be, for example, in the form of a dialogue screen. The user interface can also include any one of a mouse, a touch screen, a keyboard, a keypad, a voice reader, a voice recognizer, a dialogue screen, a menu box, a list, a check box, a toggle switch, a button or any other device that allows the user to receive information about the operation of the processing machine when the processing instruction set and / or providing information to the processing machine. Therefore, the user interface is any device that provides communication between the user and the processing machine. The information that the user provides to the processing machine through the user interface can be, for example, the form of command, data selection or some other input.

[0099] As mentioned above, the processing machine of execution instruction set utilizes user interface so that processing machine processes data for user.User interface is usually used for interacting with user to transmit information or receiving information from user by processing machine.But should be appreciated that according to some embodiments of system and method of the present invention, human user does not actually have to interact with the user interface used by processing machine of the present invention.On the contrary, it can also be expected that user interface of the present invention can interact (that is, transmit and receive information) with another processing machine rather than human user.Therefore, another processing machine can be characterized as user.In addition, it can be expected that the user interface utilized in system and method of the present invention can partially interact with another or more processing machines, and also partially interact with human user.

[0100] Those skilled in the art will readily appreciate that the present invention is susceptible to widespread use and application. Many embodiments and adaptations of the present invention other than those described herein and many variations, modifications and equivalent arrangements will be apparent or reasonably suggested by the present invention and its preceding description without departing from the spirit or scope of the present invention, according to the present invention and its preceding description.

[0101] Therefore, although exemplary embodiments related to the present invention have been described in detail herein, it should be understood that the present disclosure is only illustrative and exemplary of the present invention, and provides an enabling disclosure of the present invention. Therefore, the foregoing disclosure is not intended to explain or limit the present invention, or otherwise exclude any other such embodiments, adaptations, variations, modifications or equivalent arrangements.

Claims

1. A transaction processing ecosystem that include: Multiple data sources; Capture interface; as well as A financial transaction processing system includes a message bus and a plurality of processors connected to the message bus, wherein the plurality of processors are configured to perform the following operations: registering registration information of each of the plurality of processors using the message bus, the registration information indicating a transaction type that the corresponding processor can process; receiving, via the capture interface, raw data in a raw data format for a payment transaction, wherein the raw data includes a customer instruction; registering the original data format with the message bus, the registering comprising mapping each of a plurality of data fields of the original data format to a corresponding data field of a standard logical data model format; normalizing the raw data into standardized transaction data for the standard logical data model format based on the raw data format registry via the capture interface to provide a normalized transaction format; The standardized transaction format is published as a transaction to the message bus via the capture interface, wherein the message bus is connected to the plurality of processors so that each of the plurality of processors is notified of the publication; monitoring, by the plurality of processors and based on registration information of each of the plurality of processors, the transaction on the message bus for processing, the transaction comprising a first sub-transaction of a first transaction type and a second sub-transaction of a second transaction type, the second transaction type being different from the first transaction type; According to the registration information of a first processor among the plurality of processors, the transaction including the first sub-transaction is picked up by the first processor from the message bus for processing, wherein The first transaction type corresponds to a transaction type that can be processed by the first processor of the plurality of processors but cannot be processed by other processors of the plurality of processors; notifying the other processors of the plurality of processors of a status of the transaction picked up for processing; processing, via the first processor among the plurality of processors, the first sub-transaction of the transaction; returning the transaction processed by the first processor to the message bus and publishing the transaction including the second sub-transaction that has not been processed to the message bus for further processing by another processor of the plurality of processors; monitoring, by the plurality of processors and based on registration information of each of the plurality of processors, the transaction on the message bus that is processed by the first processor and requires further processing of the second sub-transaction; picking up, by a second processor of the plurality of processors, the transaction including the second sub-transaction from the message bus for processing, wherein the second transaction type corresponds to a transaction type that can be processed by the second processor of the plurality of processors but cannot be processed by other processors of the plurality of processors; determining whether the second processor is an endpoint for the payment transaction; and In response to determining that the second processor is the endpoint for the payment transaction, the processed standardized transaction is sent to a user interface and the payment transaction is completed.

2. The transaction processing ecosystem according to claim 1, in, The raw data is normalized into a logical data model format.

3. The transaction processing ecosystem according to claim 1, in, The registration information for the first processor includes an identification of a type of transaction that the first processor is to process.

4. The transaction processing ecosystem according to claim 1, in, The first processor further publishes an acknowledgement to the message bus.

5. The transaction processing ecosystem according to claim 1, in, The first processor publishes the transaction processed by the first processor to the message bus.

6. The transaction processing ecosystem according to claim 1, in, The first processor further performs a settlement action on the normalized transaction format.

7. The transaction processing ecosystem according to claim 1, in, The financial transaction processing system transmits the processed transactions to an external system.

8. The system according to claim 1, in, The financial transaction processing system transmits the processed transaction to the user interface.

9. A method for processing transactions in a transaction processing ecosystem, the transaction processing ecosystem comprising a financial transaction processing system having a message bus and a plurality of processors interfaced with the message bus, the method The following steps are involved: registering registration information of each of the plurality of processors using the message bus, the registration information indicating a transaction type that the corresponding processor can process; receiving, via a capture interface, raw data in a raw data format for a payment transaction, wherein the raw data includes a customer instruction; registering the raw data format with the message bus via a capture interface, the registering comprising mapping each of a plurality of data fields of the raw data format to a corresponding data field of a standard logical data model format, normalizing the raw data into standardized transaction data for the standard logical data model format based on the raw data format registry via the capture interface to provide a normalized transaction format; publishing the normalized transaction format as a transaction to the message bus via the capture interface, wherein the message bus is connected to the plurality of processors so that each of the plurality of processors is notified of the publishing; monitoring, by the plurality of processors and based on registration information of each of the plurality of processors, the transaction on the message bus for processing, the transaction comprising a first sub-transaction of a first transaction type and a second sub-transaction of a second transaction type, the second transaction type being different from the first transaction type; picking up, by a first processor among the plurality of processors and from the message bus, the transaction including the first sub-transaction for processing according to the registration information of the first processor among the plurality of processors, wherein the first transaction type corresponds to a transaction type that can be processed by the first processor among the plurality of processors but cannot be processed by other processors among the plurality of processors; notifying the other processors of the plurality of processors of a status of the transaction picked up for processing; processing, via the first processor among the plurality of processors, the first sub-transaction of the transaction; returning the transaction processed by the first processor to the message bus and publishing the transaction including the second sub-transaction that has not been processed to the message bus for further processing by another processor of the plurality of processors; monitoring, by the plurality of processors and based on registration information of each of the plurality of processors, the transaction on the message bus that is processed by the first processor and requires further processing of the second sub-transaction; picking up, by a second processor of the plurality of processors, the transaction including the second sub-transaction from the message bus for processing, wherein the second transaction type corresponds to a transaction type that can be processed by the second processor of the plurality of processors but cannot be processed by other processors of the plurality of processors; determining whether the second processor is an endpoint for the payment transaction; and In response to determining that the second processor is the endpoint for the payment transaction, the processed standardized transaction is sent to a user interface and the payment transaction is completed.

10. The method according to claim 9, in, The raw data is normalized into a logical data model format.

11. The method according to claim 9, in, The registration information for the first processor includes an identification of a type of transaction that the first processor is to process.

12. The method according to claim 9, in, The first processor further publishes an acknowledgement to the message bus.

13. The method according to claim 9, further comprising: include: The transaction processed by the first processor is published to the message bus via the first processor.

14. The method according to claim 9, in, The first processor further performs a settlement action on the normalized transaction format.

15. The method according to claim 9, in, The financial transaction processing system transmits the processed transactions to an external system.

16. The method according to claim 9, in, The financial transaction processing system transmits the processed transaction to the user interface.

Images