# US 12,118,567 B2 · Detecting and preventing duplicate transactions on a transaction exchange platform

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 12,118,567 B2
- Document ID: US12118567B2
- Status: Granted
- Kind: B2
- Application number: 18/149,544
- Filed: 2023-01-03
- Published: 2023-05-18
- Granted: 2024-10-15
- Earliest claimed: 2019-12-20
- Assignees: Capital One Services, LLC
- Applicants: Capital One Services, LLC
- Inventors: Nishant Srivastava; Eric K. Barnum; Suresh Chander Ramaraj; Eric Smith; Earle Michael Lee; Kumari Bhawprita
- Web page: https://patentgrep.com/patent/US12118567B2

## CPC

- G06Q 20/425: {using two different networks, one for transaction and one for security confirmation}
- G06F 11/008: {Reliability or availability analysis}
- G06F 11/0745: {in an input/output transactions management context (input/output processing in general G06F13/00)}
- G06F 11/0751: {Error or fault detection not based on redundancy (power supply failures G06F1/30; network fault management H04L41/06)}
- G06F 11/0757: {by exceeding a time limit, i.e. time-out, e.g. watchdogs}
- G06F 11/0793: {Remedial or corrective actions (recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40)}
- G06F 11/1405: {at machine instruction level}
- G06F 11/1474: in transactions (updating of structured data in databases G06F16/23)
- G06F 16/2379: {Updates performed during online database operations; commit processing}
- G06Q 20/02: involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q 20/085: {involving remote charge determination or related payment systems}
- G06Q 20/102: {Bill distribution or payments}
- G06Q 20/401: {Transaction verification}
- G06Q 20/407: {Cancellation of a transaction}
- G06F 2201/81: Threshold
- G06F 2201/87: Monitoring of transactions
- G06Q: INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)

## 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.

## Claims

### Claim 1

A computer-implemented method comprising:
receiving, by a transaction exchange platform, a first transaction object corresponding to a first payment transaction, wherein the first transaction object comprises first transaction details, wherein the transaction exchange platform includes a plurality of microservices;
determining, by a screening microservice of the plurality of microservices, 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;
determining, by the screening microservice and using a predictive model, whether the first transaction details indicate a likelihood that processing of the first transaction object is going to occur without any errors;
based on a determination that the first transaction object is not a duplicate of the plurality of payment transactions and based on a determination that the first transaction details indicate a likelihood that processing of the first transaction object is going to succeed, generating an identification token for the first transaction object;
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 a pre-initialization stage;
retrieving, by a client registry microservice of the plurality of microservices and based on the workflow stage of the first transaction object being set to the pre-initialization stage, a plurality of transaction objects, wherein the plurality of transaction objects comprises the first transaction object;
determining, by the client registry microservice, whether the first payment transaction is permitted based on one or more rules;
prepending, by the client registry microservice and based on a determination that the first payment transaction is permitted, a client identifier to the identification token to generate a first transaction identifier;
updating, by the client registry microservice, the workflow stage of the first transaction object to an initialization state;
adding, by the client registry microservice, the first transaction object to the streaming data platform;
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;
determining, by the validation platform, whether a format of the first payment transaction is valid;
based on a determination that the format of the first payment transaction is valid, appending a batch identifier to the first transaction identifier and adding the first 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.

### Claim 2 (depends on 1)

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.

### Claim 3 (depends on 1)

The computer-implemented method of claim 1, 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.

### Claim 4 (depends on 1)

The computer-implemented method of claim 1, wherein the determination that the first transaction details indicate a likelihood that processing of the first transaction object is going to occur without any errors is performed using one or more machine learning models.

### Claim 5 (depends on 1)

The computer-implemented method of claim 1, wherein the identification token is generated using a hash function.

### Claim 6 (depends on 5)

The computer-implemented method of claim 5, wherein the identification token comprises a predetermined number of most significant bits of a resultant of the hash function.

### Claim 7 (depends on 1)

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.

### Claim 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:
receive a first transaction object corresponding to a first payment transaction, wherein the first transaction object comprises first transaction details;
determine, by a 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;
determine, by the screening microservice and using a predictive model, whether the first transaction details indicate a likelihood that processing of the first transaction object is going to occur without any errors;
based on a determination that the first transaction object is not a duplicate of the plurality of payment transactions and based on a determination that the first transaction details indicate a likelihood that processing of the first transaction object is going to succeed, generate an identification token for the first transaction object;
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 a pre-initialization stage;
retrieve, by a client registry microservice and based on the workflow stage of the first transaction object being set to the pre-initialization stage, a plurality of transaction objects, wherein the plurality of transaction objects comprises the first transaction object;
determine, by the client registry microservice, whether the first payment transaction is permitted based on one or more rules;
prepend, by the client registry microservice and based on a determination that the first payment transaction is permitted, a client identifier to the identification token to generate a first transaction identifier;
update, by the client registry microservice, the workflow stage of the first transaction object to an initialization state;
add, by the client registry microservice, the first transaction object to the streaming data platform;
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;
determine, by the validation platform, whether a format of the first transaction is valid;
based on determination that the 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.

### Claim 9 (depends on 8)

The transaction exchange platform of claim 8, wherein the instructions, 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.

### Claim 10 (depends on 8)

The transaction exchange platform of claim 8, 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.

### Claim 11 (depends on 8)

The transaction exchange platform of claim 8, wherein the determination that the first transaction details indicate a likelihood that processing of the first transaction object is going to occur without any errors is performed using one or more machine learning models.

### Claim 12 (depends on 8)

The transaction exchange platform of claim 8, wherein the instructions, when executed by the at least one processor, cause the transaction exchange platform to generate the identification token using a hash function.

### Claim 13 (depends on 12)

The transaction exchange platform of claim 12, wherein the identification token comprises a predetermined number of most significant bits of a resultant of the hash function.

### Claim 14 (depends on 8)

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.

### Claim 15

One or more non-transitory computer readable media comprising instructions that, when executed, cause a transaction exchange platform to:
receive a first transaction object corresponding to a first payment transaction, wherein the first transaction object comprises first transaction details;
determine, by a 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;
determine, by screening microservice and using a predictive model, whether the first transaction details indicate a likelihood that processing of the first transaction object is going to occur without any errors;
based on a determination that the first transaction object is not a duplicate of the plurality of payment transactions and based on a determination that the first transaction details indicate a likelihood that processing of the first transaction object is going to succeed, generate an identification token for the first transaction object;
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 a pre-initialization stage;
retrieve, by a client registry microservice and based on the workflow stage of the first transaction object being set to the pre-initialization stage, a plurality of transaction objects, wherein the plurality of transaction objects comprises the first transaction object;
determine, by the client registry microservice, whether the first payment transaction is permitted based on one or more rules;
prepend, by the client registry microservice and based on a determination that the first payment transaction is permitted, a client identifier to the identification token to generate a first transaction identifier;
update, by the client registry microservice, the workflow stage of the first transaction object to an initialization state;
add, by the client registry microservice, the first transaction object to the streaming data platform;
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;
determine, by the validation platform, whether a format of the first payment transaction is valid;
based on determination that the 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.

### Claim 16 (depends on 15)

The one or more non-transitory computer readable media of claim 15, wherein the instructions, 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 add the first payment transaction to a second file; and
upload the second file to the portal to re-initiate the first payment transaction.

### Claim 17 (depends on 15)

The one or more non-transitory computer readable media of claim 15, 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.

### Claim 18 (depends on 15)

The one or more non-transitory computer readable media of claim 15, wherein the determination that the first transaction details indicate a likelihood that processing of the first transaction object is going to occur without any errors is performed using one or more machine learning models.

### Claim 19 (depends on 15)

The one or more non-transitory computer readable media of claim 15, wherein the instructions, when executed, cause the transaction exchange platform to generate the identification token using a hash function, wherein the identification token comprises a predetermined number of most significant bits of a resultant of the hash function.

### Claim 20 (depends on 15)

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.