Ability to filter banking transactions based on 'modified' date

[markskript]

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:

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.