Decision Proposal 021 - Non-functional Requirements

Please find attached a proposal for non-functional requirements for the CDR regime affecting both data recipients and data holders.

This proposal should be considered an initial strawman provided specifically to draw comment and feedback. It should not be considered a final position.

It should be noted that the proposal does not yet cover Security or Customer Experience NFRs. This is a known gap in the proposal. Also, it is likely that some of the areas covered by the proposal may end up being address by the ACCC Rules. This proposal has been created in consultation with the ACCC and feedback will be openly shared between the ACCC and the Standards Body.

Feedback for this version of the proposal will be closed on the 11th January 2019. Decision Proposal 021 - Non-functional Requirements.pdf

Hi James, Can you please share a clear definition of the term "session" within the proposal i.e. Number of sessions per day? During the ABA call today there was some discussion on the term and we were keen to get a clear definition from Data61.

In general the NFRs are well considered, and attempt to carter for the concerns of Data Holders and Data Receivers alike; we would however like to convey the following feedback:

API Performance

Customer Attended vs Unattended requests

Whist we understand the intent of providing different NFRs for when a customer is present or not, it is unclear how this will be implemented, monitored and controlled. The current proposal will need elaboration with respect to the protocols for how this will be communicated from a Data Receiver to a Data Holder. We require more details on the exact specification for the "origin device headers" that will be used to facilitate this handshake.

We anticipate this handshake may require a level of trust, governance and if needs be appropriate repercussions should Data Receivers implement solutions which claim customer attendance when this is not the case.

The term "session" requires clarification without it this NFR is unenforceable and open to interpretation/exploitation:

when does a session start?
when does it end? and
how long can a session remain idle before being closed? especially in scenarios where client applications do not have the concept of an explicit logout.

Get Bulk Balances - Should be a categorised within the Bulk performance tier

How will api calls that involve complicated search parameters, pagination and large page sizes impact the performance reporting metrics? We propose the NFRs should have a banding within each tier to cater for standard vs complex API calls. (e.g. a bulk API call requiring data from <10 accounts is standard and >=10 accounts is complex; so that outliers do not pollute the metrics)

Availability

It should be noted that the proposed 99.5% availability requirement is significantly higher than that of the UK's implementation requirements.

UK Open Banking Service Level Agreement

Furthermore, the definition of availability should be clearly defined to remove ambiguity. i.e. What is the definition of the service? In the current definition it appears to be cumulative, so if you have 1 API out for 30 minutes then that adds to the total as if the entire implementation is out. This could lead to a situation where misleading statistics could cause reputational damages for a Data Holders should they be responding well within the NFRs for all but one API calls. e.g. a complex bulk api call that may not impact a majority of customer use cases may experience an outage; in this instance there would be no way of distinguishing the metrics from a Data Holder who has an outage for all APIs for the same time duration.

Reporting

There are no defined NFRs for the Admin/ Reporting endpoints.

Exemptions to Protect Service

What constitutes a misbehaving service? Is this something that can be agreed upfront? This would allow Data Holders to implement the necessary controls.

When the scheme goes live the probability for disruption to service is higher during the initial few months for a number of unforeseeable reasons, with this in mind we would like to propose a grace period whereby the NFRs are reported, but do not constitute non-compliance if not met for a set period of time.

• What are the consequences if a data provider does not meet NFRs (presumably a policy question, but important to understand before committing to non-functional requirements)? • In the current proposal, availability is measured per month at 99.5%, where performance is measured per hour. We would recommend that we align the timeframe of measurement for both availability and performance to 'per month'. Per hour seems too onerous, as a 1-hour performance issue, will automatically result in a breach. • Could we please move the Get Bulk Balances API to the Bulk section? We have examples of businesses which have thousands of accounts. Additionally, if we are looking to support real-time balances, this will be difficult to achieve in bulk. • How will "high traffic periods" be defined? Is this an industry wide definition (e.g. 7am - 7pm), or per data provider? Our initial thinking is this should be defined by each data provider, as some data providers have EOD jobs they would like avoided, and these can run at various times.

The ABA Open Banking Technical Working Group considers the proposed NFR's to be, overall, reasonable and appropriate. We do however have some questions and suggestions (some of which recapitulate comments already made above):

Reporting requirements - clarification required Who will be the consumer of the report data and how often is it likely to be polled? We ask this question as the information to be reported implies some items that will require significant computational processes and the need for availability and currency of that data is questioned against the cost to derive/service it.

Data consumer requirements Regarding the point - “Services should schedule unattended calls to avoid high traffic periods” – the definition of “high traffic periods” and how they will be determined is ambiguous. It would be preferable to be more explicit - we nominate that the preferred non-high traffic period would typically be the period between 3am and 6am AEST.

Service availability We note that the service availability requirement of 99.5% availability in each month is significantly higher than the 95% availability for each day required in the UK for e.g. the open data SLA. Similarly, the traffic thresholds for which performance requirements must be met are significantly higher in this proposal when compared to the UK case. The UK Open Data SLA has a peak load of 500 requests per minute (~8.3 TPS) and 15000 requests in an 8 hour period (~0.5 TPS) vs 600 TPS across all requests for this proposal.

We do not object to these requirements however we feel it should be acknowledged that they are stringent and challenging.

Data holders should not be bound by NFR's beyond their control Non-functional requirements should only address factors within the control of Data Holders. For example, data holders are unable to influence out-of-infrastructure network latency and we suggest the removal of the phrase “…it is expected that the data provider will ensure the measurement of response is a reasonable proxy of the experience of the data consumer.” so that performance requirements are set in terms of the infrastructure controlled by data holders.

Customer present - clarification required We request details and clarity around the method of determining if calls are made with a customer present. Is the intent to use origin device headers as in the proposal or to use the x-fapi-customer-ip-address header as suggested by the current draft standard?

Performance requirements - Bulk Balances Bulk balances are not included in the Bulk teir (i.e. they must meet a significantly more challenging threshold). What is the rationale for this?

Hi James,

Some great thinking and good to have something to work through, we have a few thoughts and propositions listed below:

Response time

Recommend to have thresholds based on API and then prioritise attended.
- As part of this, propose to remove 'high priority' category and have it in the 1500ms bracket.
- Ability to drop unattended if latency is increasing on attended calls
We understand the performance requirement for response time only apply to 95% of calls, however should there also be a cap on other metrics (e.g. number of transactions in message or the like) which would then mean higher response times could be accepted for large responses.
The proposal suggested to use Origin header to determine unattended, but from initial investigation API Gateways often don't support the use of HTTP headers to apply throttling policies - is this seen as an issue for anyone? We're still investigating this point.
- We do agree that understanding attended and unattended will be very useful for prioritisation and throttling.

Traffic Thresholds

Recommend simplifying traffic thresholds to remove session and customer based limits - as these are difficult to enforce and should be managed by recipient if they desire even distribution of requests across their customers.
Recommend removing differentiation for traffic thresholds between attended and unattended.
Recommend adding traffic threshold per API (e.g. x TPS for Get Account Detail, etc). If there is no capped amount per API, this could lead to a concentration of traffic to 1 – 2 endpoints (such as balances) and therefore placing increasing load on particular backend systems, rather than an even distribution across the breadth of data and associated systems.
- This API threshold should also have per consumer thresholds included.
Would be good to have some guidance on how these numbers are expected to change (i.e. as new data consumers are added, which could then impact performance for existing consumers)
There should be a TPS threshold for Public product APIs.

In summary we would suggest thresholds for the following levels:

API
API per consumer (data recipient)
Per consumer(data recipient) total TPS
Total TPS for all consumers(data recipients)

Closed accounts

Suggest that APIs for Closed accounts should only return data (i.e. account details, balances) for accounts closed within 12 months - this then also aligns to the existing NFR on how far back transaction data needs to be available for. This is due to performance concerns if they cannot be cleaned up in a more prompt time frame.
For some account types we may not be able to provide closed account details from before go-live date. This is due to how certain systems behave for historic data.

Exemptions to protect service

Could there also be exemptions so that priority could be provided to internal traffic if there was unexpectedly high demand in rare situations? This was verbally discussed in a Data 61 meeting in Sydney, but we would like to see it in the documentation.

Happy New Year everyone. Thanks for the feedback to date. I intend to respond substantively in the next 24 hours. This feedback thread will be extended by a week until this Friday at the request of some participants.

-JB-

Responses to the above feedback is below. This has been aggregated as numerous topics were mentioned multiple times.

Definition of Session In the NFR proposal, wherever the term session is used it is synonymous with Access Token. This definition will be added to the proposal.

In addition, Access token expiry expectations will be added to the NFRs. A candidate proposal will be: Access Tokens will expire after:

10 minutes of inactivity
60 minutes total duration

Definition of Attended Now that the InfoSec stream has further defined headers the definition of “Attended” traffic will be defined as the presence of the x-fapi-customer-ip-address populated with a valid client IP address. This should be definitive and easily identifiable. It does not prevent the data recipient providing false information but this would be considered behaviour that undermines the regime and would reasonably result in sanction.

Response time classification of Bulk Balances Bulk balances have been deliberately considered a low priority as it is a common “customer present” API call and the total volume is one-to-one to the number of accounts. If outlier customers with thousands of accounts results in a miss of the response time this should be addressed by the 95% within the threshold per hour. This is also a standard retrieval for Internet Banking so it is assumed that the ability to retrieve this data rapidly is already a high priority.

It appears that the use of the “Bulk” label in the thresholds has resulted in this feedback. To clarify this situation I will relable the “Bulk” threshold tier to “Large Payload”.

In addition, regarding the comments around real time balances provided by Macquarie, it should also be noted that the NFRs do not require real time balances, only balances that match existing digital channels such as internet banking or mobile banking.

Reporing Some comments on reporting:

ACCC will be the consumer of the reporting.
It is not known how often reporting will be requested. In the absence of clear guidance the NFRs have been designed to support variable frequencies of reporting.
With regard to computation, the metrics chosen are fairly standard metrics available from most COTS gateway products and only aggregate values are expected to be stored beyond the current day so it is assumed that computation requirements will be light.

Australian vs UK NFRs The availability requirement for the Australian regime are indeed higher than the SLAs defined for the UK regime. The Australian NFRs are commensurate with industry expectations for online channels, however.

Availability NFRs The availability metric is deliberately defined as the failure of any end point. For client services dependent on these APIs the failure of any of the APIs that they rely on will result in their service being impacted.

With regard to bulk responses note that the availability definition is that an end point can not provide a successful response, not that it does not respond in the required time. The performance requirement deals with unusually large API calls by applying a 95% requirement of calls per hour to be within the threshold.

Admin End Points NFRs have not been defined for the admin/reporting end points as these are not yet proposed. When options for these end points are presented NFRs will be addressed then.

Exemptions Exemptions to protect services have been left vague for the reasons suggested in the feedback (rates will be higher in the early stages of the regime). Also a reasonable definition that was specific could not be identified. Specific proposals are welcome and will be considered.

Impact on breach The impact of not meeting the NFRs is, as suggested in feedback, a policy question. The standards body defines the standard only. It is up to the ACCC to define how breaches will be addressed.

Measurement Periods The measurement of availability by a longer period and performance by a shorter period is fairly standard across the industry. Alignment of timeframe is not of practical value in this case. A 1 hour drop in performance has real impact to the down streams systems as is useful to highlight.

Measurement of Response Time Regarding infrastructure beyond the control of the data holders, the line quoted by the ABA response was specifically included to address this issue. It is understood that the full round trip can not be reasonably measured by a data holder but the boundary point selected for measurement should be chosen as a reasonable proxy for the experience of the consumer. The implication of this is that the measurement should be done at the most practicable outer bound of the infrastructure that is in the control of the data holder. I will consider changes to the language to make this more clear.

Record Caps There was feedback indicating that payload size could impact NFRs. There is already a cap on the number of records in a response payload and the impact of NFRs was raised during that consultation. This was initially set at 500 records but the community requested this be raised to 1000 which is where it is currently set.

*“Definition of High-Traffic Periods** If a specific definition is of value then a proposal of what is reasonable would be welcome. Once a specific period is defined it would also be reasonable to add a clause indicating unattended calls during the high traffic period can be refused to protect attended traffic (but only under heavy load conditions).

Traffic Thresholds The traffic thresholds for data recipients indicate levels after which the data holder is able to throttle traffic. In response to feedback from ANZ, if these thresholds are difficult for a data holder to measure and they choose not to throttle based on these thresholds then that is within their discretion.

TPS End point specific TPS thresholds were not added due to the fact that the CDR end points are able to be easily cached. A concentration of traffic on a cacheable end point is actually a good result and should increase the overall TPS ceiling of an implementation. The feedback that endpoint level TPS thresholds should apply is also inconsistent with other feedback requesting simplification of the NFRs. This will, however, be considered further.

A TPS threshold for public APIs is an omission and will be added.

Data Extents It was suggested that the data extent NFRs should cover all account data and not just transaction data. This is reasonable and will be incorporated.

Prioritisation of Existing Digital Channels The suggestion that interactions for other digital channels should be prioritised over the CDR API channel is an interesting proposition. Before incorporating this, however, I would appreciate additional viewpoints and thoughts from the community. I understand the driver for this request due to the underlying ledger platforms being common to all channels but this approach could be seen as overly prioritising the needs for the data holders at the expense of the data recipients. Further feedback on this topic would be welcome.

-JB-

Thank you for the update and response.

We have a some more clarifications and suggestions related to this decision proposal, as follows:

Transaction data and closed accounts

Noting that accounts closed on or after 1 Jan 2017 are in scope, in this decision proposal, what does "12 months of transaction data for closed accounts should be available" and "Note that the regime has a hard limit for historic data. Data prior to 1st January 2017 does not need to be presented." specifically mean? A couple of example scenarios for clarity:

Scenario 1: For an account closed on 2/1/17, our interpretation is that that Data Holders must be able to share 2 days worth of transaction data.

Scenario 2: If an account is closed on 1/1/18, and a Data Recipient initiates a transaction data request on 2/1/19, do Data Holders present no transactions or transactions back until 1/1/17? Based on the CDR bill (explanatory memorandum), our interpretation is that transactions back until 1/1/17 are to be presented.

Direct debits and closed accounts

The proposed NFR has direct debits to be detected from transactions within the last 13 months. For closed accounts, will direct debit data only be applicable for 12 months of transaction data (or less depending on the answer to scenario 2 (above), regarding transaction data and closed accounts)?

Closed accounts

Will there be a period after which closed accounts will not be available for data sharing? Or will a customer be able to select from all accounts during the consent flow as long as the account was closed on or after 1/1/17? An example in the CDR bill (explanatory memorandum) mentions that the regulations provide that a data holder does not need to provide access to data older than six-years old.

If closed accounts available for data sharing must have been closed in the last 6 years, say, then what is the expected behaviour when overlaying consent validity period? Can the closed account drop off the 'Get Accounts' account list once that 6 year period has elapsed even if the consent period is valid?

FAPI HTTP request headers

With the proposal to use the presence of the x-fapi-customer-ip-address HTTP request header to distinguish between unattended and customer attended traffic, we suggest that the CDR Standards / InfoSec Profile adopt the following headers as mandatory for customer attended traffic. Suggested mandatory request headers for customer attended traffic:

x-fapi-customer-id
x-fapi-customer-last-logged-time (currently present in CDR Standards)
x-fapi-customer-ip-address (currently present in CDR Standards)
The original user agent of the customer device (part of decision proposal https://github.com/ConsumerDataStandardsAustralia/standards/issues/10 but not currently reflected in the CDR Standard documentation.

This information is important to Data Holder's risk based decisioning and fraud data correlation.

Similar to how the response headers and data access payloads tables have a "Mandatory? / Required" column, we suggest that Request Headers https://consumerdatastandardsaustralia.github.io/standards/?swagger#http-headers section also follows the same definition table structure.

Products and public endpoints

What is the technical definition of “public” and “unauthenticated” for the Products endpoints? What decision proposals and standards (including InfoSec profile) apply or don’t apply for the Products endpoints?

Can anyone enter https://non-mtls-subdomain.data.provider.com.au/cds-au/v1/banking/products into their internet browser and expect to get a response? Are there any mandatory (FAPI) HTTP request headers?

Our interpretation is that the endpoint would be 100% public. No mandatory (FAPI) HTTP request headers, no mTLS, no OAuth tokens, no accreditation required of the client, etc.

What controls, and NFRs can a Data Holder implement to protect the service quality for these public end points?

Hi James,

With regard to the Access token expiry expectations, the current feeling is that 60 minutes duration and a 10 minute inactivity expiry is excessive, we would be more inclined to align access tokens closer to the timings set by our App and Internet banking. ANZ’s view is that the key considerations for such parameter setting is what is an acceptable window of time to enable a session to extend, considering the function(s) this session enables. Our current App has a access token which is short lived (e.g. 3 minutes) and IB has a session of 15 minutes and an expiry after a short period of inactivity.

If we have to set a figure, we would suggest 3 minutes should be sufficient. This suggestion is due to the risk of hijacking the token and using it for malicious activity, obviously the longer the expiry time, the greater the risk of exposer.

We are keen to understand any use cases which would require tokens to have a lifespan longer than these values, consuming applications should be able to achieve all calls in a short period of time if a longer time is required they can simply apply for a new access token. However ANZ is keen to hear views from other data holders and consumers which will lead to an acceptable figure for the regime.

Final responses before I close this thread.

Data Extents The comments on data extents are noted but will be removed from the standard in response to ACCC feedback that data extents should be in the rules.

Headers I will take the feedback on board regarding headers, including a statement around optionality.

Public End Points It is expected that public end points will be fully open to any client without a requirement for authentication or authorisation. A postman call with appropriate headers to these end points should be successful.

With regards to controls, I would hesitate to provide architectural advice but it would be reasonable to apply the same controls to public APIs as to any static web pages. Controls such as WAFs, a CDN and caching would all be appropriate. Where possible these end points have been designed to be highly cacheable.

Expiry Times The times suggested seem quite short from my experience across the industry. The key driver is to accommodate the “once-off” scenario where no long term access is consented to. In this scenario 15 minutes might be too short to complete a non-trivial Product application for instance. If we did shorten the period it would be appropriate to increase some of the other thresholds proportionately to allow for a similar number of transactions (especially for unattended use).

-JB-

Please find attached the final, endorsed, decision on non-functional requirements. Decision 021 - Non-functional Requirements.pdf

ConsumerDataStandardsAustralia / standards