Efficient data processing using data aggregation parties

Abstract

A method is disclosed. The method includes receiving, by a processing computer, a payment verification message for a transaction from an aggregator computer, the aggregator computer receiving a payment query message from an initiator computer of a plurality of initiator computers. The aggregator computer is in communication with the plurality of initiator computers. The payment query message and the payment verification message may include a transaction amount for the transaction. The processing computer verifies the payment verification message and then sends a payment verification response message to the aggregator computer. The payment verification response message comprises data about verification of the payment verification message. After sending the payment verification response message to the aggregator computer, the method includes receiving, by the processing computer, a payment message from the aggregator computer. The method also includes sending, by the processing computer, a payment response message to the aggregator computer.

Description

[0001] Cross-reference to related applications

[0002] none. Background Art

[0003] Transaction systems such as cross-border payment systems face many challenges. Current cross-border payment systems connect each sender's bank (e.g., the originator bank) to a domestic correspondent bank. The domestic correspondent bank then connects to a payment processing network to perform a cross-border remittance of funds to the recipient bank. This process is often inefficient, fragmented, and opaque due to the presence of many domestic correspondent banks connected to the payment processing network. Each domestic bank needs to individually address issues such as technical verification, delivery estimates, and foreign exchange conversions. Such processes can result in slow transactions and sometimes data loss.

[0004] Embodiments of the present disclosure address this and other problems, individually and collectively. Summary of the invention

[0005] One embodiment includes a method, comprising: receiving, by a processing computer, a payment verification message of a transaction from an aggregator computer, the aggregator computer receiving a payment query message from an initiator computer among multiple initiator computers, the aggregator computer communicating with the multiple initiator computers, the payment query message and the payment verification message including the transaction amount of the transaction; verifying the payment verification message by the processing computer; in response to verifying the payment verification message, sending a payment verification response message by the processing computer to the aggregator computer, the payment verification response message including data regarding the verification of the payment verification message; after sending the payment verification response message to the aggregator computer, receiving a payment message from the aggregator computer by the processing computer; and sending a payment response message by the processing computer to the aggregator computer.

[0006] Another embodiment includes a method, comprising: receiving, by an aggregator computer, a payment query message from an initiator computer among a plurality of initiator computers; sending, by the aggregator computer, a payment verification message of a transaction to a processing computer, and the processing computer verifying the payment verification message; receiving, by the aggregator computer, a payment verification response message from the processing computer, and the payment verification response message including data regarding the verification of the payment verification message; sending, by the aggregator computer, a payment message to the processing computer; and receiving, by the aggregator computer, a payment response message from the processing computer.

[0007] A better understanding of the nature and advantages of embodiments of the present invention may be obtained by reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A swim-lane diagram showing the cross-border remittance message sequence.

[0009] Figure 2 Swim lane diagram of a cross-border remittance message sequence showing a canceled transaction.

[0010] Figure 3 Swim lane diagram showing the cross-border remittance message sequence for a returned transaction.

[0011] Figure 4-6 Screen shots showing the user experience when making a cross-border money transfer, according to an embodiment.

[0012] Figure 7 A block diagram of a processing computer according to an embodiment is shown.

[0013] Figure 8 A block diagram of an aggregator computer according to an embodiment is shown. DETAILED DESCRIPTION

[0014] Before discussing specific embodiments in detail, some terms may be described in detail.

[0015] A "user" may include a person or a computing device. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may be a sender of funds or a receiver of funds.

[0016] A "user device" may be any suitable device (e.g., a payment card or mobile phone) that can interact with a user device. The user device may take any suitable form. Some examples of user devices include cellular phones, PDAs, personal computers (PCs), tablet computers, etc. In some embodiments where the user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable components. A user as a sender may have a user device, which may be a sender device. A user as a receiver may have a receiver device, which may be a receiver device.

[0017] A "processor" may include any suitable one or more data computing devices. A processor may include one or more microprocessors that work together to achieve the desired functionality. A processor may include a CPU that includes at least one high-speed data processor sufficient to execute program components that are used to execute user and / or system generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0018] "Memory" may be any suitable device or devices that can store electronic data. Suitable memory may include non-transitory computer-readable media that stores instructions that can be executed by a processor to implement the desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic modes of operation.

[0019] A sender associated with an originator operating an originator computer (e.g., a sender bank) may perform a transaction involving a cross-border remittance to transfer value (e.g., funds) to a receiver associated with a receiver entity operating a receiver entity computer (e.g., a receiver bank). To perform the transaction, the originating entity sends the transfer value to a domestic correspondent entity (e.g., a domestic correspondent bank). The domestic correspondent entity may then send the transfer value to a foreign correspondent entity via a processing network. The foreign correspondent bank may then send the transfer value to a receiver entity, thereby completing the transaction.

[0020] There are problems with such methods of executing transactions involving cross-border remittances to transfer value. One problem is that such methods lack visibility. There may be hundreds of originating and receiving entities, as well as multiple domestic counterpart entities and foreign counterpart entities. For example, if there are 100 originating parties and 50 domestic counterpart entities, there are 5,000 possible combinations on one side of the cross-border remittance system alone. Because transactions may involve so many combinations of entities, it may be difficult to predict the costs and time associated with all remittances, as each entity may charge different fees and may take different times to process transactions. It may also result in payment data loss, as there may be some processing inconsistencies between entities with so many different transaction route combinations. Another problem is that current cross-border remittance transactions are slow because each domestic entity needs to individually resolve issues such as technical verification, delivery estimates, and foreign exchange conversion for each transaction. It typically takes three to five business days to complete a transaction.

[0021] Figure 1 A system diagram and flow chart illustrating a method according to an embodiment in which a real-time payment is sent from a sender 102 to a receiver (not shown) associated with a receiver entity computer 114, which may be operated by a receiver entity such as a financial institution (e.g., a bank) that holds an account with the receiver.

[0022] In addition to the recipient entity computer 114, the system includes an originator computer 104, a transfer computer 106, an aggregator computer 108, a processing computer 110, and a partner computer 112. These computers are in operable communication with each other.

[0023] The originator computer 104 may be operated by an originator, which may be a financial institution (eg, a bank) that holds an account for the sender 102 .

[0024] The transfer computer 106 may perform real-time transfers of funds between the originator computer 104 and the accumulator computer 108. An example of a transfer computer may be a computer operated by an FPS or Fast Payment Service.

[0025] The processing computer 110 may be in operative communication with the aggregator computer 108 and the partner computer 112 to facilitate cross-border remittances. The recipient entity may be associated with the recipient entity computer 114. The recipient may be associated with the recipient entity computer 114 by having an account in the recipient entity. The partner computer 112 may transfer the payment to the recipient entity computer 114, and the recipient entity computer 114 may credit the recipient account in the recipient entity of the payment.

[0026] The transfer computer 106 may be a computer capable of performing real-time payment transactions (e.g., Fast Payment Service (FPS)). The aggregator computer 108 may be operated by an aggregation entity and may communicate with multiple originator computers. In some embodiments, the aggregator computer 108 may maintain a matching account (e.g., a pool account) for each of the multiple originator computers. The aggregator computer 108 may act as a gateway for multiple originator computers to the processing computer 110.

[0027] The processing computer 110 may include a server computer for processing data. In some embodiments, the processing computer may be used to process transactions from a network. In some embodiments, the processing computer may be coupled to a database and may include any hardware, software, other logic, or a combination of the foregoing items for providing services for requests from one or more client computers or user devices. The processing computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to serve requests from one or more client computers or user devices. In some embodiments, the processing computer may operate multiple server computers. In such embodiments, each server computer may be configured to process transactions for a given area or manage specific types of transactions based on transaction data.

[0028] Processing computer 110 may include data processing subsystems, networks, and operations to support and provide authorization services, exception file services, and clearing and settlement services. Exemplary processing computers may include VisaNet TM . Including VisaNet TM VisaNet is a network that processes credit card transactions, debit card transactions, and other types of commercial transactions. TM Includes an Integrated Payments system that processes authorization requests, and a Base II system that performs clearing and settlement services. The processing computer can use any suitable wired or wireless network, including the Internet.

[0029] The processing computer 110 may process transaction-related messages (e.g., authorization request messages and authorization response messages) and determine the appropriate destination computer (e.g., issuer computer / authorization entity computer) for the transaction-related messages. In some embodiments, the processing computer may authorize transactions on behalf of the issuer. The processing computer may also process and / or facilitate clearing and settlement of financial transactions.

[0030] The partner computer 112 may be operated by a network partner entity such as a financial institution. The financial institution may be a hub or gateway for multiple recipient entity computers operated by a recipient entity, such as a recipient financial institution (e.g., a recipient bank) that holds a recipient account. In some embodiments, the partner computer 112 may maintain a matching account (e.g., a pool account) for each of the multiple recipient entity computers.

[0031] Figure 1 (as well as Figure 2-4) can communicate via any suitable communication channel or communication network. Suitable communication networks can be any one of the following and / or a combination thereof: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an operating mission as a node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as, but not limited to, wireless application protocol (WAP), I-mode, etc.); and the like.

[0032] In some embodiments, the sender 102, the originator computer 104, the transfer computer 106, and the aggregator computer 108 may be in one country (e.g., the United States), while the partner computer 112, the recipient entity computer 114, and the recipient having an account maintained by the recipient entity computer 114 may be in another country (e.g., France). The entire system can efficiently and securely allow funds to be transferred from the sender 102 to the recipient across borders.

[0033] One embodiment of the present invention includes a method, the method comprising receiving, by a processing computer, a payment verification message of a transaction from an aggregator computer, the aggregator computer receiving a payment query message from an initiator computer among a plurality of initiator computers. The aggregator computer communicates with the plurality of initiator computers. The payment query message and the payment verification message may include a transaction amount of the transaction. The processing computer verifies the payment verification message and then sends a payment verification response message to the aggregator computer. The payment verification response message includes data regarding the verification of the payment verification message. After sending the payment verification response message to the aggregator computer, the method comprises receiving, by the processing computer, a payment message from the aggregator computer. The method also comprises sending, by the processing computer, a payment response message to the aggregator computer.

[0034] In step S102, the sender 102 may use a user device such as the sender device to communicate with the originator computer 104 (e.g., via an application or browser on the user device) to input data to perform a transaction from the sender's 102 account to the recipient's ( Figure 1 In some embodiments, the sender 102 and the receiver may be located in different countries. The input data may include transaction details, including at least the transaction amount, the currency of the country to which the user wants to send money, and the statement narrative, and recipient details, including at least the recipient's first name, the recipient's last name, and the recipient's account number.

[0035] In step S104, after receiving data to perform a funds transfer from the sender 102's account to the recipient's account, the initiator computer 104 may generate a payment query message. The payment query message may include payment instructions, initiator data, transaction data, recipient data, and sender data. The initiator data may include an initiator ID, an initiator name, and an initiator address. The payment query message may also have a transaction identifier that may identify the transaction. The transaction identifier may be present in Figure 1 The Pay Query message may be used by an originating entity operating an originator computer 104 to inquire whether a funds transfer requested by a sender 102 is feasible, the time it will take to make the funds transfer, and any other information that the originator computer 204 or sender 202 may use to authorize the funds transfer (e.g., a currency exchange rate for the transfer).

[0036] The transaction data may include details of the transaction. The transaction data may include at least the transaction amount, the currency of the country to which the user wants to transfer money, and the statement narrative.

[0037] The recipient data may include at least the recipient's first name, the recipient's last name, and the recipient's account number at the recipient's financial institution (eg, an IBAN number).

[0038] The sender data may include at least the sender's first name, the sender's last name, the sender's address, the sender reference number, and the source of funds (eg, a masked account number of the sender's account).

[0039] After generating the payment inquiry message, in step S104 , the initiator computer 204 may send the payment inquiry message to the transfer computer 106 .

[0040] In step S106 , after receiving the payment query message, the transfer computer 106 may send the payment query message to the syndicator computer 108 .

[0041] In step S108, the facilitator computer 108 may send a payment verification message to the processing computer 110 via a first API (application programming interface) such as a payment verification API or any other suitable means. The payment verification message may contain at least the same information as in the payment query message, and may also include information about the facilitator computer 108 (e.g., ID or address).

[0042] In step S110, after receiving the payment verification message, the processing computer 110 verifies the payment verification message. The processing computer 110 may perform a technical verification process and may estimate the delivery time of the funds transfer. The technical verification may include checking whether the payment verification message has all the implementation details required to successfully conduct the transaction. For example, a country such as the United Kingdom may have different implementation details for cross-border transactions than France. For example, the United Kingdom may have more implementation details for incoming cross-border funds transfers than France. The processing computer 110 may check the data in the payment verification message to determine whether it complies with the implementation details of the recipient's country. In this regard, the processing computer 110 may have a table listing various countries along with the implementation details required to perform cross-border transactions and the expected funds transfer time for each country.

[0043] In step S112, after performing the verification process on the pay verification message, the processing computer 110 may send a pay verification response message to the facilitator computer 108. The pay verification response message may indicate that the technical verification was successful (or unsuccessful) and may further provide an estimated time to make the funds transfer.

[0044] In step S114, after the syndicator computer 108 receives the payment verification response message, the syndicator computer 108 may send a rate query request message to the processing computer 110. The rate query request message may be an API call made by the processing computer 110 via a third API, such as an exchange rate query API, to determine the conversion rate and / or processing fee for the requested funds transfer.

[0045] In step S116, the processing computer 110 may determine the conversion rate and processing fee for the funds transfer. In some embodiments, the conversion rate may be determined using the address or location of the sender 102 and / or the originator (e.g., the sender's bank) and the currency described in the transaction details in the payment inquiry and payment verification messages described above.

[0046] In step S118, after determining the currency conversion rate for the requested funds transfer, the processing computer 110 may send a rate query response message including the conversion rate and / or any processing fees to the syndicator computer 108.

[0047] It should be noted that in some embodiments, if the transfer is not a cross-border transfer, the rate query steps S114, S116 and S118 may be omitted, or the rate query step may be combined with the payment verification message in steps S108, S110 and S112.

[0048] After step S118, the syndicator computer may store the data in the payment query message, the payment verification response and the rate query response together with the transaction identifier in a database. This data may be saved so that it can be used to construct or generate a payment message as in step S138 below.

[0049] In step S120, after receiving the rate query response message, the syndicator computer 108 may generate a payment query response message and send it to the transfer computer 106. The payment query response message may include some or all of the information in the payment verification response message in step S112 and the rate query response message in step S118.

[0050] In step S122 , after receiving the payment query response message, the money transfer computer 106 may send the payment query response message to the originator computer 104 .

[0051] In step S124, the originator computer 104 may present (e.g., via an application or browser) some or all of the data in the pay query response message to the sender 102 via the sender's user device. Such data may include an estimated delivery time for the funds transfer (e.g., 1 day), a conversion rate (e.g., 1.1 francs per U.S. dollar), a processing fee, an amount to be debited from the sender's 102 account, and an amount to be credited to the recipient.

[0052] In step S126, after receiving the data about the funds transfer, the sender 102 may analyze the data about the funds transfer and may review any terms and conditions of the funds transfer. The sender 102 may then indicate on the sender's 102 user device that the sender 102 agrees to the funds transfer.

[0053] In step S128 , the sender's consent may then be provided to the originator computer 104 .

[0054] In step S130 , after the originator computer 104 receives consent from the sender 102 , the originator computer 104 may construct a real-time funds transfer message to transfer funds of at least the current funds transfer amount from the originator computer 104 to the aggregator computer 108 via the transfer computer 106 .

[0055] In step S132, after receiving the real-time funds transfer message, the transfer computer 106 may perform a real-time funds transfer process from the originator computer 104 to the syndicator computer 108 for at least the transaction amount. The syndicator computer 108 may maintain a single account in which real-time funds transfers are received from the originator of the originator computer 104 and other originators operating other originator computers. Examples of real-time funds transfer systems include FPS (Fast Payment Service), FedNow Service, etc. In some embodiments, the funds transfer between the originator computer 104 and the syndicator computer 108 may be a domestic transfer.

[0056] In step S134, the transfer computer 106 may send a confirmation of the successful real-time funds transfer to the originator computer 104. The confirmation may indicate that the transaction amount has been debited to the sender's account.

[0057] In step S136, the transfer computer 106 may send a confirmation regarding the real-time funds transfer to the syndicator computer 108. The confirmation may indicate that the transaction amount has been credited to an account associated with the syndicator operating the syndicator computer 108.

[0058] At this point in the process, the aggregator computer 108 has the funds necessary to perform the funds transfer from the sender 102 to the recipient.

[0059] In step S138, after receiving the funds from the originator computer 104, the syndicator computer 108 may send a pay message (e.g., via a second API such as a pay API) to the processing computer 110. The pay message may have the necessary data required to facilitate the payment from the sender to the recipient. The syndicator computer 108 may retrieve data about the funds transfer stored after step S118.

[0060] In step S140, after the processing computer 110 receives the payment message from the syndicator computer 108, the processing computer 110 may verify the payment message. The processing computer 110 may verify the payment message in any suitable manner, including verifying the originator data, transaction data, recipient data, and sender data. Verification may include checking whether such data is authentic and / or not on a negative list, and whether the data is properly formatted for processing. Once verified, the processing computer 110 may queue the payment message for review.

[0061] In step S142, while the payout message is in the queue for review, a payout response message may be sent from the processing computer 110 to the facilitator computer 108. The payout response message may be a notification indicating that the payout has been received by the facilitator computer 108.

[0062] In steps S144, S146 and S148, status notifications regarding the funds transfer may be sent from the accumulator computer 108 to the transfer computer 106, from the transfer computer 106 to the originator computer 104, and from the originator computer 104 to the sender 102 (via the sender's user device).

[0063] In step S150, the processing computer 110 may perform a review process of the transaction after verifying the payment message. An example of performing a review process may be detecting any suspicious activities, such as securities fraud, according to anti-money laundering (AML) regulations.

[0064] In step S152, after successful payment review, the processing computer 110 may send a payment message to the partner computer 112. The partner computer 112 may be operated by a financial institution operating in the recipient country. The payment message may transfer funds from the aggregator computer 108 to the partner computer 112 via the processing computer 110. In some cases, the transfer may occur in real time.

[0065] In step S154, after the partner computer 112 receives the pay message, the partner computer 112 may send the pay message to the recipient entity computer 114. The recipient entity (e.g., a financial institution or bank holding a recipient account) may then notify the recipient that the funds associated with the funds transfer have been received. In some embodiments, the partner computer 112 may then transfer the funds to the recipient entity computer 114 via an automated rapid payment process such as a clearing house (ACH) process or a real-time payment (RTP) process. The recipient entity computer 114 may then credit the recipient account with the amount of the transfer.

[0066] In step S156, the partner computer 112 may send a pay response message to the processing computer 110, the pay response message indicating that the funds were successfully transferred to the recipient.

[0067] In steps S158 , S160 , S162 , and S164 , a final status notification of the value transfer may be sent from the processing computer 110 to the sender 102 via the syndicator computer 108 , the transfer computer 106 , and the originator computer 104 .

[0068] In some embodiments, Figure 1After step S140 in , the processing computer 110 may request additional information to successfully complete the payment review. The processing computer 110 may perform a review process for the transaction after verifying the payment message. An example of performing a review process may be to detect any suspicious activities, such as securities fraud, in accordance with anti-money laundering (AML) regulations. During the review, the processing computer 110 may require additional information from the originator computer 104 to process the transaction. The additional information may include credential information, the purpose of the funds transfer, etc. The processing computer 110 may obtain the additional information and may complete the review process for the funds transfer.

[0069] Figure 2 The diagram illustrates a system and flow chart showing a money transfer cancellation process initiated by the sender 102. Before the funds transfer occurs between the aggregator computer 108 and the partner computer 112, the sender 102 can cancel the funds transfer transaction.

[0070] In step S248, a status notification that the processing computer has received the payment response message may be sent from the initiator computer 204 to the sender 202. This is similar to Figure 1 Step S148 in .

[0071] In step S202 , the sender 202 may send a payment cancellation request message to the initiator computer 104 .

[0072] In steps S204 , S206 and S208 , a payment cancellation request message may be sent from the originator computer 204 to the processing computer 210 via the transfer computer 206 and the syndicator computer 208 .

[0073] In step S210, after receiving the payment cancellation request message, the processing computer 210 may check whether the fund transfer between the syndicator computer 108 and the partner computer 112 via the processing computer 110 has not yet occurred.

[0074] In step S212, after verifying that the funds transfer has not occurred, the processing computer 110 may cancel the transaction and send a payment cancellation response message to the facilitator computer 108. The payment cancellation response message may include the amount that should be transferred to the recipient.

[0075] In step S214 , a payment cancellation response message may be sent from the syndicator computer 108 to the transfer computer 106 .

[0076] In step S216, the transfer computer may initiate a real-time value transfer from the syndicator computer 108 to the originator computer 104. In some embodiments, during the real-time value transfer, the transfer computer 106 may send instructions to the central bank of the sender country and perform settlement between the originator and the syndicator. The value (e.g., funds) transfer between the originator computer 104 and the syndicator computer 108 may be a domestic transfer.

[0077] In step S218, the transfer computer 106 may send a confirmation of the successful real-time value transfer to the syndicator computer 108. The confirmation may indicate that the value has been debited to the originator's matching account in the syndicator computer 108.

[0078] In step S220, the transfer computer 106 may send a confirmation of the successful real-time value transfer to the syndicator computer 108. The confirmation may indicate that the transaction amount has been credited to the sender account in the originator computer 104.

[0079] In step S222, once the sender's account is credited, the originator computer 104 can send a notification to the sender 102 of the successful cancellation of the money transfer.

[0080] Figure 3 A flow chart showing the system and the sequence of money transfer messages returned by the recipient entity computer 114 for a transaction.

[0081] In step S354, the partner computer 112 may send a payment message to the recipient entity computer 114. This is similar to Figure 1 The network partner entity associated with the partner computer 112 may then transfer the value of the transfer amount via an automated clearing house (ACH) or real-time payment (RTP) to a recipient entity operating the recipient entity computer 114. The recipient entity computer 114 may then credit the transfer amount to the recipient account.

[0082] In step S302, the recipient entity computer 114 may review the payment message. After reviewing the payment message, the recipient entity computer 114 may reject the transaction and fail to credit the transaction amount to the recipient account. The recipient entity computer 114 may reject the transaction due to poor credit status, a frozen recipient account, a failed review, etc.

[0083] In step S304, the recipient entity computer 114 may construct a payment return message including a transaction rejection notification. In some embodiments, the payment return message may include a reason for the rejection. The payment return message may then be sent from the recipient entity computer 114 to the partner computer 112.

[0084] In steps S306 , S308 and S310 , a pay-back message may be sent from the partner computer 112 to the transfer computer 106 via the processing computer 110 and the syndicator computer 108 .

[0085] In step S312 , the transfer computer may initiate a real-time value transfer from the syndicator computer 108 to the originator computer 104 .

[0086] In step S314, the transfer computer 106 may send a confirmation of the successful real-time value transfer to the syndicator computer 108. The confirmation may indicate that the value has been debited to the originator's matching account in the syndicator computer 108.

[0087] In step S316, the transfer computer 106 may send a confirmation of the successful real-time value transfer to the syndicator computer 108. The confirmation may indicate that the transaction amount has been credited to the sender account in the originator computer 104.

[0088] In step S318, once the sender account of the originator computer 104 is credited, the originator computer 104 can send a notification to the sender 102 of the successful cancellation of the money transfer.

[0089] Figure 4-6 102 shows a screenshot of what a user may see when interacting according to an embodiment. It may show an example flow chart of actual interaction of a sender 102 with a user device for remittance. The user device may have a program or application in its user device that a user may interact with to perform a transaction (e.g., a transfer transaction such as a cross-border remittance). The program or application may be associated with an initiator (e.g., a sender's bank) operating an initiator computer.

[0090] The user may have selected an option before screen 402 to perform a cross-border money transfer. Screen 402 may be the first screen that may be displayed to the user when selecting the option to perform a cross-border money transfer.

[0091] In screen 402, the user may be prompted to fill in the recipient's information in the application. Since the user information including the details of the initiator and the sender is stored in the initiator, the application may require the sender to provide the recipient's information for the cross-border remittance. The application may prompt the user to fill in the recipient's full name with input field 402A, and prompt the user to fill in the recipient's country with input field 402B. Screen 402 may additionally provide an input field for the sender to write the recipient's nickname. The user may click on input field 402B to select a country.

[0092] In screen 404, a list of countries may be presented to the user from which the user may select. The user may search for the recipient's country by using search bar 404A. The screen may also display a list 404B showing popular countries, and a list 404C showing all countries that the user may select. The user may select the country to which the recipient belongs. Upon clicking on the country, which in this example is the United Kingdom, a new screen is presented in 502.

[0093] In screen 502, the user may be presented with Figure 4 402, but with the fields filled in. In this particular example, the user has filled in the name "Brian Miller" in the input field 502A, and has selected the country "United Kingdom" in the input field 502B, and has filled in "British Pounds (GBP)" in the input field 502C. An input field 502C is provided for selecting a currency, as the country may have a multi-currency system. For example, in this figure, the user may select Euros instead of GBP. Once the name, country, and currency are selected, the user may select a button 502D for "Add Payee" to continue the transaction.

[0094] In screen 504, the user is presented with an input field 504A for the transaction amount in the sender's currency and an input field 504B for the transaction amount in the recipient's currency. The sender's currency is displayed in input field 504C, and the recipient's currency is displayed in input field 504D. Other details of the recipient can be filled in box 504E in screen 504, which displays the transaction details and recipient information.

[0095] In screen 506, the user is presented with a screen to enter transaction notes 506A, bank name 506B, IBAN number 506C, and the recipient's SWIFT code 506D. The sender may need this information to successfully perform a transaction with the correct recipient. When filling in the information, the sender can select button 506E to "Add Card".

[0096] refer to Figure 6 In screen 602, the user may be presented with Figure 5602B. The user enters the amount they want to send, and this value is calculated together with the sum of the transaction fees. In this example, a user in Russia is shown entering 50 GBP to a person in the UK in the input field. This 50 GBP is converted to 5007.13 rubles (RUB) and displayed in input field 602A. In addition to the conversion, it also calculates the total amount including the fees that the sender needs to pay for the transfer. The conversion can be done in other ways, where the sender can enter the amount in rubles that it wants to send to the recipient in input field 602A, and the application calculates the amount in GBP in input field 602B. The total amount is displayed in small box 602C, where the sender needs to pay a total amount of 5023.13 RUB to transfer 50 GBP to the recipient. Once the user is notified of this information, the user can click button 602D to continue.

[0097] In screen 604, a summary / review page may be displayed. The summary page may include the sender's account 604A, the recipient's information 604B, the recipient's account information 604C, an option to select whether it is a recurring payment 604D, and a transaction summary 604E including payment details. The user may review the transaction details one last time before sending the amount to the recipient. Once the user has reviewed the transaction details, the user may confirm the transaction by clicking button 604F.

[0098] In screen 606, a confirmation page may be displayed. Details of the transaction may be shown in 606A. To exit the confirmation page, the user may select a "Done" button 606B.

[0099] Figure 7 A block diagram of a processing computer 700 according to an embodiment is shown. The processing computer 700 may include a processor 702. The processor 702 may be coupled to an input element 703, an output element 705, a memory 704, a network interface 709, and a computer readable medium 708. The computer readable medium 708 may include any suitable number and type of software modules.

[0100] Examples of input elements may include a microphone, a keypad, a touch screen, a sensor, etc. Examples of output elements may include a speaker, a display screen, and a haptic device.

[0101] The memory 704 may be used to store data and code. The memory 704 may be coupled to the processor 702 internally or externally (e.g., via a cloud-based data storage) and may include any combination of volatile and / or non-volatile memory such as RAM, DRAM, ROM, flash, or any other suitable memory device. In some embodiments, the memory 704 may store data items of a payload.

[0102] The network interface 706 may include an interface that allows the processing computer 700 to communicate with an external computer. The network interface 706 may enable the processing computer 700 to transmit data to and from another device, such as an aggregation computer, a partner computer, etc. Some examples of the network interface 706 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a personal computer memory card international association (PCMCIA) slot and card, etc. The data transmitted via the network interface 706 may be in the form of a signal, which may be an electrical signal, an electromagnetic signal, an optical signal, or any other signal (collectively referred to as an "electronic signal" or "electronic message") that can be received by an external communication interface. These electronic messages, which may include data or instructions, may be provided between the network interface 706 and other devices via a communication path or channel. As noted above, any suitable communication path or channel may be used, including but not limited to wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, etc.

[0103] The computer-readable medium 708 may include code executable by the processor 702 for performing operations including the following: receiving a payment verification message of a transaction from an aggregator computer, the aggregator computer receiving a payment query message from an initiator computer among multiple initiator computers, the aggregator computer communicating with the multiple initiator computers, the payment query message and the payment verification message including the transaction amount of the transaction; verifying the payment verification message; in response to verifying the payment verification message, sending a payment verification response message to the aggregator computer, the payment verification response message including data regarding the verification of the payment verification message; after sending the payment verification response message to the aggregator computer, receiving a payment message from the aggregator computer; and sending a payment response message to the aggregator computer.

[0104] The computer-readable medium 708 may include several software modules, including but not limited to a query verification module 708A, a conversion module 708B, a payment verification module 708C, and a review module 708D.

[0105] The query verification module 708A may perform a technical verification on the payment verification message received from the aggregator computer. The technical verification may include checking whether the payment verification message has all the implementation details required to successfully conduct the transaction. For example, for cross-border remittances, the UK may require different implementation details than Russia. The technical verification ensures that the payment verification message has all the implementation details specific to the recipient's country. The query verification module 708A may additionally estimate the delivery time of the value transfer.

[0106] The conversion module 708B may check the currency conversion rate of the transaction amount in the rate query request message. The conversion module 708B may additionally calculate a processing fee to perform the transaction (eg, a cross-border remittance equivalent transfer transaction).

[0107] The payment verification module 708C may include verifying the payment message. The payment verification module 708C may verify the originator details, transaction details, recipient details, and sender details of the payment message. The review module 708D may review the payment message after verifying the payment message. An example of performing a review process may be to detect any suspicious activities, such as securities fraud, in accordance with anti-money laundering (AML) regulations.

[0108] Figure 8 A block diagram of an accelerator computer 800 according to an embodiment is shown. The accelerator computer 800 may include a processor 802. The processor 802 may be coupled to an input element 803, an output element 805, a memory 804, a network interface 806, and a computer readable medium 808. The computer readable medium 808 may include any suitable number and type of software modules.

[0109] Examples of input elements may include a microphone, a keypad, a touch screen, a sensor, etc. Examples of output elements may include a speaker, a display screen, and a haptic device.

[0110] The memory 804 may be used to store data and code. The memory 804 may be coupled to the processor 802 internally or externally (e.g., via a cloud-based data storage) and may include any combination of volatile and / or non-volatile memory such as RAM, DRAM, ROM, flash, or any other suitable memory device. In some embodiments, the memory 804 may store data items of a payload.

[0111] The network interface 806 may include Figure 7 The network interface 706 in may have the same or different features, so its description is incorporated herein.

[0112] The computer-readable medium 808 may include code executable by the processor 802 for a method comprising: receiving a payment query message from an initiator computer among a plurality of initiator computers; sending a payment verification message of a transaction to a processing computer, the processing computer verifying the payment verification message; receiving a payment verification response message from the processing computer, the payment verification response message including data regarding the verification of the payment verification message; sending a payment message to the processing computer; and receiving a payment response message from the processing computer.

[0113] The computer readable medium 808 may include several software modules including, but not limited to, a payout verification API module 808A, a conversion rate API module 808B, a payout API module 808C, and a notification module 808D.

[0114] The payment verification API module 808A may send a payment verification message to the processing computer 700. The payment verification message may be an API call of a payment inquiry message received from the transfer computer for technical verification and delivery estimation. The conversion rate API module 808B may send a rate inquiry request message to the processing computer 700. The rate inquiry request message may be an API call of a payment inquiry message received from the transfer computer for currency conversion rate and calculation of currency conversion rate.

[0115] The payment API module 808C can send the payment message received from the facilitator computer as an API call to the processing computer. By sending the payment message as an API call, the processing computer 700 can verify the payment message and review the payment message.

[0116] Embodiments of the present invention have several technical advantages. One advantage of the present invention is that transactions are more transparent. Embodiments may use a single aggregator computer. The aggregator computer may solve problems such as technical verification, delivery estimates, and exchange rate conversion for many originators. Because there is a single aggregator computer (and optionally a single partner computer) to facilitate transactions (e.g., cross-border fund transfers) through a processing network, the combination of entities that may be involved in the transaction is limited to the number of initiator entities and recipient entities. For example, as noted in the example above, if there are 100 initiators and 50 intermediaries as in a conventional system, there may be 5,000 possible combinations. However, in an embodiment, there may be one aggregator for 100 initiators, so there are only 100 possible combinations. In addition, an embodiment may use an API to standardize the formatting and transmission of data between the aggregator computer and the processing computer. The combination of these features can produce more accurate, more predictable, and faster transactions than conventional systems. Another advantage of an embodiment is the use of a transfer computer. The transfer computer enables real-time fund transfers between any originator and its corresponding aggregator, thereby ensuring that the time from when the sender requests a fund transfer to when the recipient actually receives the funds is minimized.

[0117] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, and suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or a digital versatile disk (DVD), flash memory, etc. The computer-readable medium can be any combination of such storage or transmission devices.

[0118] The above description is illustrative rather than restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims together with their full scope or equivalents.

[0119] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0120] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A method comprising: Receiving, by the processing computer, a payment verification message of the transaction from the aggregator computer, the aggregator computer receiving a payment inquiry message from an initiator computer among a plurality of initiator computers, the aggregator computer communicating with the plurality of initiator computers, the payment inquiry message and the payment verification message including a transaction amount of the transaction; verifying, by the processing computer, the payment verification message; In response to verifying the payment verification message, sending, by the processing computer, to the facilitator computer, a payment verification response message, the payment verification response message including data regarding the verification of the payment verification message; receiving, by the processing computer, a payout message from the facilitator computer after sending the payout verification response message to the facilitator computer; and The processing computer sends a response message to the facilitator computer.

2. The method of claim 1, wherein the transaction is a cross-border funds transfer between a sender in one country and a receiver in another country.

3. The method of claim 1, wherein verifying the payment verification message comprises: The payment verification message is determined by the processing computer to have the implementation details required to successfully conduct the transaction.

4. The method according to claim 1, further comprising: The processing computer receives a rate query request message from the aggregator computer; determining the conversion rate for said transaction; as well as In response to determining the conversion rate for the transaction, a rate query response message including the conversion rate is sent by the processing computer to the syndicator computer.

5. The method of claim 1 , wherein the transaction is a value transfer transaction that transfers value from a sender associated with an initiator operating the initiator computer to a recipient, wherein the recipient is associated with a receiving entity operating a recipient entity computer that communicates with the processing computer.

6. The method of claim 1, wherein the aggregator computer is a gateway for the plurality of initiator computers to the processing computer.

7. The method of claim 1, wherein the payout verification message is provided from the syndicator computer to the processing computer via a first API, and the payout verification response message is provided from the processing computer to the syndicator computer via the first API.

8. The method of claim 7, wherein the payout message is provided by the syndicator computer to the processing computer via a second API, and the payout response message is provided by the processing computer to the syndicator computer via the second API.

9. The method according to claim 1, further comprising: verifying, by the processing computer, the payment message; A review process of the transaction is performed by the processing computer after verifying the payment message.

10. The method according to claim 9, further comprising: sending, by the processing computer, an examination information request providing additional information for use in the examination process; as well as An audit information response message having the additional information is received by the processing computer.

11. The method according to claim 9, further comprising, after performing the review process: The processing computer sends the payment message to the partner computer, the partner computer transfers the transaction amount to the recipient entity computer, and the recipient entity computer credits the transaction amount to the recipient account.

12. The method of claim 1, wherein the facilitator computer stores data in the payout query message in a database and uses the data to generate the payout message.

13. The method of claim 12, wherein the payment verification message, the payment verification response message, the payment message, and the payment response message each contain the same transaction identifier.

14. The method according to claim 1, further comprising: The processing computer sends a status notification of the transaction to the syndicator computer, and the syndicator computer sends the status notification to the initiator computer.

15. The method of claim 1 , wherein the aggregator computer sends the payment response message to the initiator computer via a transfer computer, and wherein after the initiator computer receives the payment response message, the initiator computer 104 constructs a real-time funds transfer message to transfer at least the transaction amount from the initiator computer to the aggregator computer via the transfer computer.

16. A system comprising: A processing computer comprising a processor and a computer readable medium comprising code executable by the processor to perform operations comprising: receiving a payment verification message for a transaction from an aggregator computer, the aggregator computer receiving a payment inquiry message from an initiator computer among a plurality of initiator computers, the aggregator computer communicating with the plurality of initiator computers, the payment inquiry message and the payment verification message including a transaction amount of the transaction; Verifying the payment verification message; In response to verifying the payment verification message, sending a payment verification response message to the syndicator computer, the payment verification response message including data regarding the verification of the payment verification message; receiving a payout message from the syndicator computer after sending the payout verification response message to the syndicator computer; and In response to validating the pay message, a pay response message is sent to the facilitator computer.

17. The system of claim 16, further comprising the aggregator computer.

18. A method comprising: Receiving, by the aggregator computer, a payment query message from an initiator computer among the plurality of initiator computers; The aggregator computer sends a payment verification message of the transaction to the processing computer, and the processing computer verifies the payment verification message; receiving, by the facilitator computer, a payment verification response message from the processing computer, the payment verification response message including data regarding verification of the payment verification message; sending a payment message from the syndicator computer to the processing computer; and A pay response message is received by the facilitator computer from the processing computer.

19. The method of claim 18, wherein the payment inquiry message and the payment verification message include a transaction amount of the transaction.

20. The method of claim 18, wherein in the method, the facilitator computer and the processing computer communicate via an API.

Images