Note: This is an older version of our APIs, click here to check out the newer APIs.
Overview
The reconciliation logic for duplicate transactions is explained here through different problem scenarios and proposed solutions.
Problem Statement 1
(Applicable to all containers)
In the case of agent issues, duplicate transactions are filed at the Yodlee database. These transactions are imported into the customer’s database. When Yodlee identifies and deletes these transactions from the database as part of clean-up, the customer does not get an update. Thus the duplicates continue to exist at the customer’s end.
Solution 1
Proactive Fixing - The customer can implement logic to match all transactions coming through the API with those that exist in their database and then file the transactions one by one.
- Match the transactionId and don’t file the existing transactions. If there is any change in transactional data please update such transactions.
- For transactions with the new transactionId, the rule that they can run follows:
transaction date/ post date + amount + description + baseType + status
The customer can use either transaction date or post date based on availability. They can scale this approach by matching the incoming transactions with last 30 days of transactions present in their database.
Solution 2
Reactive Fixing - The customer finds the duplicates and then files a bug. Once reported Yodlee does the clean-up of data and responds to confirm that the duplicates have been removed. In this case they will have to again call the transactionSearch API for the reported period and then delete those transactions that do not appear in the response. transactionID can be used for comparing and deleting the transactions.
Problem Statement 2
(Applicable to all containers)
Duplication caused by pending transactions.
Solutions
Following are the suggested three solutions:
- The customer should not store the pending transactions.
- Store the pending transactions only for one day and delete them.
- Make the call for 5 or 7 days of historical transactions using the filter and compare transactionIDs and delete the transactions that are not returned for that time frame but are present in customer’s database for that period.