This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41
stars
9
forks
source link
Ability to filter banking transactions based on 'modified' date #676
There is a desire from both Accredited Data Recipients (ADR’s) and Data Holders (DH’s) to reduce the number of API calls that need to be made from the ADR to the DH as part of business-as-usual product offerings. Unfortunately, there are parts of the standard which currently force ADRs to make more API calls than they would like. One of those areas is the “oldest-time” filter on the Banking Get Transactions for Account endpoint.
The current definition of the “oldest-time” parameter, obtained from here, is as follows:
Constrain the transaction history request to transactions with effective time at or after this date/time. If absent defaults to newest-time minus 90 days. Format is aligned to DateTimeString common type
The “effective time” is then further defined as:
For the purpose of filtering and ordering it is expected that the data holder will use the "effective" date/time which will be defined as:
Posted date/time if available, then
Execution date/time if available, then
A reasonable date/time nominated by the data holder using internal data structures
If the ADR wishes to obtain “all new transactions, or transactions that have changed, since I last collected transactions” then there are currently only 2 solutions available.
Obtain a FULL list of ALL transactions every time we wish for an update, and then handle the “duplicates” (which has its own issues due to optional unique IDs on transactions and transactions moving from PENDING to POSTED)
Obtain a “sliding window” of transactions and hope that no transactions have been updated outside of that window, and also handle the complex update logic.
Both those solutions require ADRs to make more API calls to the DH than is optimal, increasing system load and affecting TPS requirements.
Area Affected
Get Transactions For Account
Change Proposed
We propose introducing a new parameter named modified-since to the Get Transactions on Account API call. This would allow the ADR to specifically request only transactions that have been created or mutated since that date.
The parameters to the Get Transactions on Account API call would be altered as follows
New Parameters
The following new parameter would be defined
Name
In
Type
Required
Description
modified-since
query
DateTimeString
conditional - optional but cannot be provided in combination with either the oldest-time or newest-time parameter.
Constrain the transaction history request to transactions that have been created or modified at or after this date/time.
Updates to existing parameters
The “Required” definition for the following two parameters would be updated from ‘optional’ to ‘conditional’
Name
Required
oldest-time
conditional - optional but cannot be provided in combination with the modified-since parameter
newest-time
conditional - optional but cannot be provided in combination with the modified-since parameter
The structure of the response to this API call would be unchanged, bar the filtering as defined above.
Alternate Options
This change has been discussed at the NFR working group. The following alternate options were also identified as part of preparing this paper and are open for discussion.
Alternate 1 - An event-driven, webhook-based, approach for active notification of updated data from the DH to the ADR. While we see the benefits for this in the future, especially in areas of Action Initiation, we feel that a more strategic option is warranted in the short term.
Alternate 2 - An e-tag based approach where the DH provides a ‘tag’ in the response to the Banking Transactions call. This tag can be presented by the ADR at the next call in order to represent a request for “transactions that have changed since the tag was provided”.
Alternate 3 - Altering the existing definition of "effective-time" in the existing query logic, rather than defining a new field. This would provide the extra benefit of allowing a phased-deployment with minimal API impact.
Description
There is a desire from both Accredited Data Recipients (ADR’s) and Data Holders (DH’s) to reduce the number of API calls that need to be made from the ADR to the DH as part of business-as-usual product offerings. Unfortunately, there are parts of the standard which currently force ADRs to make more API calls than they would like. One of those areas is the “oldest-time” filter on the Banking Get Transactions for Account endpoint.
The current definition of the “oldest-time” parameter, obtained from here, is as follows:
The “effective time” is then further defined as:
If the ADR wishes to obtain “all new transactions, or transactions that have changed, since I last collected transactions” then there are currently only 2 solutions available.
Obtain a FULL list of ALL transactions every time we wish for an update, and then handle the “duplicates” (which has its own issues due to optional unique IDs on transactions and transactions moving from PENDING to POSTED)
Obtain a “sliding window” of transactions and hope that no transactions have been updated outside of that window, and also handle the complex update logic.
Both those solutions require ADRs to make more API calls to the DH than is optimal, increasing system load and affecting TPS requirements.
Area Affected
Get Transactions For Account
Change Proposed
We propose introducing a new parameter named modified-since to the Get Transactions on Account API call. This would allow the ADR to specifically request only transactions that have been created or mutated since that date.
The parameters to the Get Transactions on Account API call would be altered as follows
New Parameters
The following new parameter would be defined
Updates to existing parameters
The “Required” definition for the following two parameters would be updated from ‘optional’ to ‘conditional’
The structure of the response to this API call would be unchanged, bar the filtering as defined above.
Alternate Options
This change has been discussed at the NFR working group. The following alternate options were also identified as part of preparing this paper and are open for discussion.
Alternate 1 - An event-driven, webhook-based, approach for active notification of updated data from the DH to the ADR. While we see the benefits for this in the future, especially in areas of Action Initiation, we feel that a more strategic option is warranted in the short term.
Alternate 2 - An e-tag based approach where the DH provides a ‘tag’ in the response to the Banking Transactions call. This tag can be presented by the ADR at the next call in order to represent a request for “transactions that have changed since the tag was provided”.
Alternate 3 - Altering the existing definition of "effective-time" in the existing query logic, rather than defining a new field. This would provide the extra benefit of allowing a phased-deployment with minimal API impact.