Reporting of data sharing rejections

Question

Is the following classification of reportable data sharing rejections correct?

Types of data sharing rejections that do not need to be reported as refusals  under rule 9.4(d):

• Any bad request, for example malformed, missing or invalid header or fields in request URI or request body.
• Method not supported, API version not supported, unacceptable header, unsupported payload format or page out of range.
• Accredited Data Recipient (ADR) could not be verified, for example due to missing or invalid certificates, or status not active with the Registry, or ADR or ADR software product not found in the Registry, or software product does not match ADR.
• The requested URI is not a CDR defined endpoint
• Customer is not eligible anymore

Data sharing rejections that should be reported as refusals under Rule 9.4(d):

• Too many requests within a timeframe (more requests than NFRs specify)
• Timeouts

Data sharing rejections due to requests before obligation dates: 

• Requests for consumer details/payees before Nov21
• Requests in relation to closed accounts before Nov21
• Requests for business accounts before Nov22
• Requests for direct debit data for closed account post Nov21
• Requests for transactions that happened more than 12 months before an account was closed (account closed within last 24 months)
• Requests for transaction that happened more than 7 years ago
• Requests for direct debits that happened more than 13 months ago post Nov21
• The requested resource URL is a valid API endpoint defined by the Consumer Data Standards, but it is not implemented or not currently supported before Feb22. The CDR Rules allow for the API to be unsupported.
• Same scenario as above, but in this case the Rules do not allow for the API to be unsupported. Either the DH has a special exemption or has failed to implement the API by the requested time.

When data is requested before the obligation date, should the response be an error, an empty response field, or no response at all? If the response is an error, is this to be reported as a refusal under rule 9.4(d)?

What if the request includes out-of-scope data? For example, a request to the Get Bulk Direct Debits API, post Nov21, that includes a closed account.

Answer

The classification of rejections in the first two lists accords with statements by the regulator.

Timeout may be considered an error rather than a rejection, however it is still reportable.

With regard to phasing of obligations, a Data Holder (DH) that is not yet obliged to implement a specific end point, or has an exemption, should respond with a 404 status, rather than an empty payload. The rejection is not considered a refusal.

Regarding a request for out-of-scope data, this is covered by other features of the standards. Direct debits can be requested only for valid account IDs, and the ADR does not have receive a valid account ID for an out of scope account. If a valid account changes status or is detached from the consent then the account Id is also no longer valid.

In both instances the response is a 422 status, with the appropriate error URN for the specific circumstance. 

See:

• CDR Rules, Main section, Part 9, Division 9.3, section 9.4 Reporting requirements, (1) (d)
• CDS Error 404
• CDS Error 422