US-12619995-B2 - Detecting and preventing duplicate transactions on a transaction exchange platform

US12619995B2US 12619995 B2US12619995 B2US 12619995B2US-12619995-B2

Abstract

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are received, the transactions may be analyzed to detect duplicate transactions and/or errors in the transactions. The transaction exchange platform may take steps to remediate transactions that are recognized as duplicates or predicted to generate one or more errors. Similarly, the transaction exchange platform may take steps to remediate transactions that are rejected by a clearinghouse.

Inventors

Nishant Srivastava
Eric K. Barnum
Suresh Chander Ramaraj
Eric Smith
Earle Michael Lee
Kumari Bhawprita

Assignees

CAPITAL ONE SERVICES, LLC

Dates

Publication Date: 20260505
Application Date: 20240911

Claims (20)

1 . A computer-implemented method comprising: retrieving, by a client registry microservice from a streaming data platform and based on a workflow stage of a first transaction object being set to a pre-initialization stage, a plurality of transaction objects, wherein the plurality of transaction objects comprises a first transaction object associated with a first payment transaction; determining, by a screening microservice and using a predictive model, whether first transaction details associated with the first payment transaction indicate a likelihood that processing of the first transaction object is going to occur without errors; prepending, by the client registry microservice and based on a determination that processing of the first payment transaction is likely to succeed without errors, a client identifier to an identification token, associated with the first transaction object, to generate a first transaction identifier; updating, by the client registry microservice, the workflow stage of the first transaction object to an initialization state; based on a determination that the workflow stage of the first transaction object indicates that the transaction object has completed processing, removing the first transaction object from the streaming data platform and outputting the first transaction object to a validation platform; based on a determination that a format of the first payment transaction is valid, appending a batch identifier to the first transaction identifier and adding the first payment transaction to a file; and uploading the file to a portal to initiate the first payment transaction and a plurality of transactions contained in the file.
2 . The computer-implemented method of claim 1 , further comprising: receiving, in response to uploading the file to the portal, an indication that processing of the file has failed; based on the indication that processing of the file has failed, generating, by the validation platform, a second batch identifier, wherein the second batch identifier is different from the batch identifier; appending the second batch identifier to the first transaction identifier and adding the first payment transaction to a second file; and uploading the second file to the portal to re-initiate the first payment transaction.
3 . The computer-implemented method of claim 1 , wherein the identification token is generated using a hash function.
4 . The computer-implemented method of claim 3 , wherein the identification token comprises a predetermined number of most significant bits of a resultant of the hash function.
5 . The computer-implemented method of claim 1 , wherein: the first payment transaction is an Automated Clearing House (ACH) transaction; and the file is a National Automated Clearing House Association (NACHA) file.
6 . The computer-implemented method of claim 1 , further comprising: determining, by the screening microservice, whether the first transaction object is a duplicate payment transaction by comparing the first transaction details to a data structure comprising transaction details of a plurality of payment transactions; wherein the generating the identification token for the first transaction object is further based on a determination that the first transaction object is not a duplicate of the plurality of payment transactions; and adding the first transaction object to a streaming data platform, wherein adding the first transaction object to the streaming data platform comprises setting a workflow stage of the first transaction object to the pre-initialization stage.
7 . The computer-implemented method of claim 6 , wherein the determination that the first transaction object is not a duplicate of the plurality of payment transactions is based on a number of the first transaction details not matching a number of transaction details associated with any of the plurality of payment transactions.
8 . A transaction exchange platform comprising: at least one processor; and memory storing instructions that, when executed by the at least one processor, cause the transaction exchange platform to: retrieve, by a client registry microservice from a streaming data platform and based on a workflow stage of a first transaction object being set to a pre-initialization stage, a plurality of transaction objects, wherein the plurality of transaction objects comprises a first transaction object associated with a first payment transaction; determine, by a screening microservice and using a predictive model, whether first transaction details associated with the first payment transaction indicate a likelihood that processing of the first transaction object is going to occur without errors; prepend, by the client registry microservice and based on a determination that processing of the first payment transaction is likely to succeed without errors, a client identifier to an identification token, associated with the first transaction object, to generate a first transaction identifier; update, by the client registry microservice, the workflow stage of the first transaction object to an initialization state; based on a determination that the workflow stage of the first transaction object indicates that the transaction object has completed processing, remove the first transaction object from the streaming data platform and outputting the first transaction object to a validation platform; based on a determination that a format of the first payment transaction is valid, append a batch identifier to the first transaction identifier and add the first payment transaction to a file; and upload the file to a portal to initiate the first payment transaction and a plurality of transactions contained in the file.
9 . The transaction exchange platform of claim 8 , wherein the instructions that, when executed by the at least one processor, cause the transaction exchange platform to: receive, in response to uploading the file to the portal, an indication that processing of the file has failed; based on the indication that processing of the file has failed, generate, by the validation platform, a second batch identifier, wherein the second batch identifier is different from the batch identifier; append the second batch identifier to the first transaction identifier and add the first payment transaction to a second file; and upload the second file to the portal to re-initiate the first payment transaction.
10 . The transaction exchange platform of claim 8 , wherein the identification token is generated using a hash function.
11 . The transaction exchange platform of claim 10 , wherein the identification token comprises a predetermined number of most significant bits of a resultant of the hash function.
12 . The transaction exchange platform of claim 8 , wherein: the first payment transaction is an Automated Clearing House (ACH) transaction; and the file is a National Automated Clearing House Association (NACHA) file.
13 . The transaction exchange platform of claim 8 , wherein the instructions that, when executed by the at least one processor, cause the transaction exchange platform to: determine, by the screening microservice, whether the first transaction object is a duplicate payment transaction by comparing first transaction details associated with the first payment transaction to a data structure comprising transaction details of a plurality of payment transactions, wherein generating the identification token for the first transaction object is further based on a determination that the first transaction object is not a duplicate of the plurality of payment transactions; and add the first transaction object to a streaming data platform, wherein adding the first transaction object to the streaming data platform comprises setting a workflow stage of the first transaction object to the pre-initialization stage.
14 . The transaction exchange platform of claim 13 , wherein the determination that the first transaction object is not a duplicate of the plurality of payment transactions is based on a number of the first transaction details not matching a number of transaction details associated with any of the plurality of payment transactions.
15 . One or more non-transitory computer-readable media comprising instructions that, when executed, cause a transaction exchange platform to: retrieve, by a client registry microservice from a streaming data platform and based on a workflow stage of a first transaction object being set to a pre-initialization stage, a plurality of transaction objects, wherein the plurality of transaction objects comprises a first transaction object associated with a first payment transaction; determine, by a screening microservice and using a predictive model, whether first transaction details associated with the first payment transaction indicate a likelihood that processing of the first transaction object is going to occur without errors; prepend, by the client registry microservice and based on a determination that processing of the first payment transaction is likely to succeed without errors, a client identifier to an identification token, associated with the first transaction object, to generate a first transaction identifier; update, by the client registry microservice, the workflow stage of the first transaction object to an initialization state; based on a determination that the workflow stage of the first transaction object indicates that the transaction object has completed processing, remove the first transaction object from the streaming data platform and outputting the first transaction object to a validation platform; based on a determination that a format of the first payment transaction is valid, append a batch identifier to the first transaction identifier and add the first payment transaction to a file; and upload the file to a portal to initiate the first payment transaction and a plurality of transactions contained in the file.
16 . The one or more non-transitory computer-readable media of claim 15 , wherein the instructions that, when executed, cause the transaction exchange platform to: receive, in response to uploading the file to the portal, an indication that processing of the file has failed; based on the indication that processing of the file has failed, generate, by the validation platform, a second batch identifier, wherein the second batch identifier is different from the batch identifier; append the second batch identifier to the first transaction identifier and adding add the first payment transaction to a second file; and upload the second file to the portal to re-initiate the first payment transaction.
17 . The one or more non-transitory computer-readable media of claim 15 , wherein the identification token comprises a predetermined number of most significant bits of a hash function.
18 . The one or more non-transitory computer-readable media of claim 15 , wherein: the first payment transaction is an Automated Clearing House (ACH) transaction; and the file is a National Automated Clearing House Association (NACHA) file.
19 . The one or more non-transitory computer-readable media of claim 15 , wherein the instructions that, when executed, cause the transaction exchange platform to: determine, by a screening microservice of the streaming data platform, whether the first transaction object is a duplicate payment transaction by comparing first transaction details associated with the first payment transaction to a data structure comprising transaction details of a plurality of payment transactions, wherein generating; the identification token for the first transaction object is further based on a determination that the first transaction object is not a duplicate of the plurality of payment transactions; and add the first transaction object to a streaming data platform, wherein adding the first transaction object to the streaming data platform comprises setting a workflow stage of the first transaction object to the pre-initialization stage.
20 . The one or more non-transitory computer-readable media of claim 19 , wherein the determination that the first transaction object is not a duplicate of the plurality of payment transactions is based on a number of the first transaction details not matching a number of transaction details associated with any of the plurality of payment transactions.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. application Ser. No. 18/149,544, filed on Jan. 3, 2023 and entitled “Detecting and Preventing Duplication Transactions on a Transaction Exchange Platform,” which is a continuation-in-part of U.S. application Ser. No. 17/389,045, filed on Jul. 29, 2021 and entitled “Transaction Exchange Platform with Watchdog Microservice,” which is a continuation of U.S. application Ser. No. 16/723,545 (now U.S. Pat. No. 11,080,120), filed on Dec. 20, 2019 and entitled “Transaction Exchange Platform with Watchdog Microservice,” the entireties of which are incorporated herein by reference. This application is related to the following U.S. patent applications, filed on the same day: U.S. application Ser. No. 18/149,444, entitled “Removing Duplicate Transactions from a Transaction Exchange Platform” and filed on Jan. 3, 2023;U.S. application Ser. No. 18/149,522, entitled “Transaction Exchange Platform for Handling Returned Transactions” and filed on Jan. 3, 2023; andU.S. application Ser. No. 18/149,493, entitled “Transaction Exchange Platform with a Validation Microservice for Validating Transactions Before Being Processed” and filed on Jan. 3, 2023. Each of the related applications is incorporated by reference herein in its entirety for all purposes. TECHNICAL FIELD OF THE INVENTION Aspects of the disclosure relate generally to a transaction exchange platform. More specifically, aspects of the disclosure may provide for detecting and/or preventing duplicate transactions. Additional aspects of the disclosure may provide for remediating one or more errors associated with transactions and, more specifically, duplicate transactions. BACKGROUND OF THE INVENTION Computer systems and applications have revolutionized the handling of transactions and greatly accelerated clearing and settlement processes. Software solutions have been created to facilitate processing, validation, and approval of transactions. These systems serve to interface transaction originators with clearing and settlement operations, allowing transactions to flow between enterprises and facilitating the movement of trillions of dollars per year. Yet regulations, security, and risk management processes have grown increasingly important and detailed, thereby complicating the approval and settlement of transactions. Further, any issues with a transaction may cause the transaction to fail out. In particular, duplicates in transaction processing are part of an industry-wide challenge facing institutions that process transactions and/or transfer money. For example, an error in certain types of transaction files, such as National Automated Clearing House Association (NACHA) files, may cause the entire transaction file to fail, which could delay the processing of up to $9.999 billion dollars. Errors in these types of files are fairly common due to the requirements of the file. For example, NACHA files require that each transaction contained therein have a unique, 15-digit identifier and all the dates be Julian. Moreover, NACHA files have to be sent to the Federal Automated Clearing House (FedACH) system via the NACHA standard. Any errors may cause the transaction file (e.g., NACHA file) to be returned to the financial institution to correct the error. If there is an error, the transaction would have to be re-worked, outside the system, and re-submitted. And, until the error is found, removed or corrected, and the file re-processed, all transactions in that file may be delayed. This causes delays to both the financial institution and its customers. Further, this puts an increased burden on the payment processing systems of the financial institution. These outcomes are undesirable since they result in delays in processing transactions, which disrupt customer experiences and leads to lost revenue. In an attempt to address potential problems, financial institutions would attempt to detect duplicate transactions using spreadsheet row checking and/or database integrity checking. In this regard, most payment originators use spreadsheets to manage transactions and transaction processing. Spreadsheet row checking would sort the spreadsheet by column and use macros to identify potential, duplicate transactions. Any duplicate transactions would then be corrected manually prior to being uploaded to a vendor, or other electronic data exchange (EDE) system, that interfaces with the FedACH system. However, spreadsheet row checking is time-intensive and prone to user-errors. Database integrity checking, on the other hand, is when a database assigns a unique identifier (e.g., a foreign key) to identify each transaction uniquely. However, the problem with assigning a unique identifier to each transaction means that even duplicate transactions will receive a unique identifier. Accordingly, duplicate transactions may be missed and included in the transaction file. Moreover, the error may be compounded and miss