[1.5.0] BPAY crnType introduced as mandatory and backported into existing version

[perlboy]

Description

The 1.5.0 release introduced crnType into BankingBillerPayee making it mandatory while backporting this to Version 1 of the payload.

This simultaneously led to the following issues:

1. An existing payload and existing version now has a new value
2. The new value is now expected to be mandatory which means any implementations against 1.4.0 will be non compliant
3. There is no guidance on what the behaviour should be if the CRN type is unknown
4. There is no guidance on what the behaviour should be if it is unknown if it is Variable or Intelligent (due to backend system support)

This item was raised in the implementation call today and a comment was made that objections weren't raised within the proposal which I believe is a reference to Decision Proposal 134. This proposal states the following:

The DP explicitly called out this change as breaking with a July 2021 date but the 1.5.0 release deliberately backported this modification into Endpoint Version 1 resulting in issues (1) and (2).

In addition, multiple participants in the linked discussion (@WestpacOpenBanking @NationalAustraliaBank) , explicitly called out issues (3) and (4).

Area Affected

BankingBillerPayee and all upstream payloads and endpoints that change as a result of changing it's structure.

Change Proposed

1. Increment the Get Payee Detail endpoint to V2 and align it's obligation date with July 2021
2. Increment all upstream payloads to V2
3. Remove INTELLIGENT_CRN until clarity regarding system support can be given

[WestpacOpenBanking]

As per issue #324, we would also appreciate clarification of the obligation date and version for the modifications to the Get Payee Detail endpoint.

In addition to the issues mentioned above, in the v1.5.0 standards release, the description of crn in BankingBillerPayee has been updated to include new statements which say that ‘sensitive’ data should be masked both using the rules applicable to the MaskedPanString common type and in alignment with online channels. It is unclear how data holders should determine which CRNs are sensitive or which of the two mentioned masking methods should apply in any given case.

We would appreciate the following clarifications:

• Was the intended interpretation that when CRNs match the format of PANs then they should be deemed sensitive and masked? Are there any new cases which should now be masked?
• Which of the two masking methods mentioned in the description should we apply?

[perlboy]

Following the call there and rollback there are two components:

1. Can the November obligation include an urgent change to provide clarity regarding conditional and clarification of the statement BPAY CRN of the Biller. If the contents of the CRN match the format of a Credit Card PAN then it should be masked using the rules applicable for the MaskedPANString common type, for instance "Where the CRN is not recorded, such as for variable CRNs, a blank value MUST be supplied"
2. The introduction of the crnType should provide clarity regarding how Holders should behave when they have a variable CRN but cannot identify if it is an intelligent CRN. Should they simply display it as VARIABLE ?

[perlboy]

I note the analysis conducted on 12 November and provide the following comments:

1. There are existing implementations of this previously mandatory field as a consequence of the publication of 1.5.0 which have been backported into the payloads whose versions weren't incremented. Given the method of reversion (big diff with unrelated alterations) used in 1.5.1 Biza.io deprioritised the upgrade to 1.5.1 for it's Babelfish (Payload), Thumb (Recipient Library), Prak (Recipient Sandbox) and Deep Thought (Resource Server) software pending clarity on path forward with relation to the tickets we opened nearly 2 months ago. These pieces of software are in use by both active and soon to be active recipients and holders within the ecosystem. In addition our payload conformance tool (Sensomatic) is in active use by organisations many of which utilise a particular core banking system with heavy adoption within Tier 3/4s. That is to say, we are validating these holders in accordance with the last non breaking published version and consequently are mandating this field in accordance with the published standard resulting in the omission of entries which cannot comply with this business rule.
2. The impact analysis does not consider Early Non-Major Data Holders which will soon account for at least 20% of the active holders and whom will go live with 1.5.0 prior to this proposed change being ratified but in reality are likely to far outnumber the Big 4 in the coming months.

In essence, if this change had been implemented in accordance with the original decision proposal the analysis would be more accurate however it does not consider that the definition of V1 of the target payloads is no longer clearly defined.

[CDR-API-Stream]

Hi all, analysis below.

Background

Related GitHub Issues:

• CRN in BankingBillerPayee should be optional #152
• [1.5.0] BPAY crnType introduced as mandatory and backported into existing version #320

Current Situation

In Maintenance iteration 4, a change was approved for BPAY CRN and the introduction of a BPAY CRN Type. This change had identified a July 2021 future dated obligation but the standards were changed without setting an obligation date. Upon review of this and the DSB's process, this change was reversed by the Data Standards Chair and the existing standards definition for BPAY CRN was re-instated.

This change request looks at how to deal with BPAY CRNs for intelligent and variable CRNs in a current state as well as the ideal target state with a clear future dated obligation.

Because "crn" is a mandatory field (although it is described as conditional, this is to accommodate masked credit card PANs, not conditional for absent CRNs), to be compliant with the data standards, any payee without a crn must be omitted from the list of biller payees. This is undesirable, hence a need for a change.

Problem Statement

Currently CRN must be provided in the BankingBillerPayee record but this cannot accommodate variable and intelligent CRNs where the CRN is not known or cannot be inferred.

Consequently, BPAY biller payee data must be omitted if the saved payee represents a variable or intelligent CRN leading to an incomplete set of payees available via Get Payee Detail.

Key considerations

Variable and Intelligent CRNs are not always known by banks. Whilst in some cases they may, they are unlikely to be relevant or populated for biller payees. Whilst support through the CRN Type can be utilised, its purpose is more relevant for transactions or scheduled payments.

This would require conditional support to populate the CRN when the type is determined to be variable or intelligent. Similarly, consideration should be given to whether a default value should be applied for the CRN Type for Biller Payees.

The change is being considered to BankingBillerPayee which has upstream API endpoint impact to:

• Get Scheduled Payments for Account v1
• Get Scheduled Payments Bulk v1
• Get Scheduled Payments For Specific Accounts v1
• Get Payee Detail v1

Indirectly, the following API endpoints are also impacted by this change request:

• Get Transactions For Account v1
• Get Transaction Detail v1

This is because these two endpoints present a CRN as a valid transaction reference. The inclusion of the type of CRN ought to be considered for banking transactions as well. Further to this, the definition of the CRN in the banking transaction response is inconsistent with the BankingBillerPayee reference which also considers the CRN to be masked where the CRN contains a credit card PAN.

Options

Option A - No Change
No change is made and any biller payees without a CRN would not be returned.

Description of the CRN is updated to make clear the masking requirements for sensitive information.

This option would mean that Variable and Intelligent BPAY billers would not be returned in the list of payees and reduce the set of BPAY payees that are shared. This is seen as the least ideal option because it results in an incomplete data set and a non ideal end state.

Option B - Make CRN Optional
CRN is made optional where the data holder does not collect it or cannot identify it or derive it. No CRN Type is defined.

The description of the CRN is updated to make clear the masking requirements for sensitive information.

The type of CRN is not provided to the client and future changes which may make it easier to consistently determine the type of CRN would not be possible.

Option C - Introduce CRN Type and make CRN conditional
CRN is made conditional where the data holder does not collect it, or cannot identify it / derive it, but mandatory if the CRN is known to be a fixed CRN. CRN Type is introduced as an optional value so that it can be provided when known otherwise defaulting to fixed CRN to provide a default that applies for existing payee data.

Where a CRN is not provided, the CRN Type is ignored. Where a bank cannot determine if a CRN is intelligent, the VARIABLE_CRN value can be used for CRN Type.

The description of the CRN is updated to make clear the masking requirements for sensitive information.

This allows for all BPAY biller payee data to be shared. It also allows the variable CRN Type to be used where the DH cannot determine that the CRN is an intelligent CRN.

Recommendation

Option C is recommended.

To accommodate variable and intelligent CRNs, the following changes are proposed. Changes to existing descriptions or conditionality are italicised:

Model	Field	Field Conditionality	Field Description	Change required
BankingTransaction	crn	conditional	BPAY CRN for the transaction (if available). Must be present if the type of CRN is FIXED_CRN. Where the CRN is not available, the value must be absent. Where the CRN contains sensitive information, it should be masked in line with how the Data Holder currently displays account identifiers in their existing online banking channels. If the contents of the CRN match the format of a Credit Card PAN they should be masked according to the rules applicable for MaskedPANString. If the contents are are otherwise sensitive, then it should be masked using the rules applicable for the MaskedAccountString common type.	Change CRN to require masking under appropriate circumstances. This change is being made to make it clear the pre-existing requirements for CRN values and it is not considered a breaking change. Affects: Get Transactions For Account v1 Get Transaction Detail v1
BankingTransaction	crnType	optional	Denotes the type of CRN of the transaction if it is available. FIXED_CRN: A unique reference number such as a credit card or a fixed reference number identifying a customer's account that does not change with each bill. FIXED_CRN is assumed if absent. VARIABLE_CRN: Biller generated reference number provided to the customer that is unique to each bill. INTELLIGENT_CRN: Biller generated reference number provided to the customer that is unique to each bill which fixes the amount of the bill being paid, expiry date or both. *If CRN is provided but crnType is absent, a default of FIXED_CRN is assumed.	Change to accommodate a CRN type, where it is known. This provides further information to the client about the CRN. This is not considered a breaking change because vs v1.5.0 of the data standards, this change proposes the field is only conditionally populated when known and when it cannot be derived, a null value is sufficient (that is, treat it as optional).  This means clients could continue to consume the payload response without breaking their implementation because this new field would provide additive informational data not required data. Affects: Get Transactions For Account v1 Get Transaction Detail v1
BankingBillerPayee	crn	conditional	BPAY CRN of the Biller (if available). Must be present if the type of CRN is FIXED_CRN. Where the CRN is not available, the value must be absent. Where the CRN contains sensitive information, it should be masked in line with how the Data Holder currently displays account identifiers in their existing online banking channels. If the contents of the CRN match the format of a Credit Card PAN they should be masked according to the rules applicable for MaskedPANString. If the contents are are otherwise sensitive, then it should be masked using the rules applicable for the MaskedAccountString common type.	Change CRN to require masking under appropriate circumstances. The CRN is required where the CRN is a FIXED_CRN and is known for the payee. This is not considered a breaking change because vs v1.5.0 of the data standards, this change proposes the field is only conditionally populated when known.  This means that current implementations would not be required to change their interface contract with the client. They would only require a data change to be more complete (see next statement). This removes the current limitation where Data Holders cannot present the CRN when the payee reference includes a variable or intelligent CRN. Affects: Get Scheduled Payments for Account v1 Get Scheduled Payments Bulk v1 Get Scheduled Payments For Specific Accounts v1 Get Payee Detail v1
BankingBillerPayee	crnType	optional	Denotes the type of CRN if available. FIXED_CRN: A unique reference number such as a credit card or a fixed reference number identifying a customer's account that does not change with each bill. FIXED_CRN is assumed if absent. VARIABLE_CRN: Biller generated reference number provided to the customer that is unique to each bill. INTELLIGENT_CRN: Biller generated reference number provided to the customer that is unique to each bill which fixes the amount of the bill being paid, expiry date or both. *If CRN is provided but crnType is absent, a default of FIXED_CRN is assumed.	Change to accommodate a CRN type, where it is known. This provides further information to the client about the CRN. This is not considered a breaking change because vs v1.5.0 of the data standards, this change proposes the field is only conditionally populated when known and when it cannot be derived, a null value is sufficient (that is, treat it as optional).  This means clients could continue to consume the payload response without breaking their implementation because this new field would provide additive informational data not required data. Affects: Get Scheduled Payments for Account v1 Get Scheduled Payments Bulk v1 Get Scheduled Payments For Specific Accounts v1 Get Payee Detail v1

Implementation Considerations

The primary consideration has been to propose changes that do not result in a breaking change to the end point schema and thus versioning of affected end points.

Whilst there may be a change to the data that can now be provided by data holders (without being non-compliant with the standards), the approach has been to minimise impact to existing data holders and those under build including reciprocal data holders.

The changes proposed will have some impact to ADR clients wanting take advantage of the additional context however this is seen as minimal.

Contrasted to the approach taken in Maintenance Iteration 4 which resulted in CRN and CRN Type being mandatory and a breaking change, this change proposal seeks to apply defaults where they cannot be determined. Further to this, it considers the broader impact of CRN and BPAY billers beyond just the Get Payee end points.

Impacted Endpoints

• Get Scheduled Payments for Account v1
• Get Scheduled Payments Bulk v1
• Get Scheduled Payments For Specific Accounts v1
• Get Payee Detail v1
• Get Transactions For Account v1
• Get Transaction Detail v1

Because this change is considered as a non-breaking interface contract change to data holder implementations, this would not result in versioning of the affected endpoints. All end points would remain at v1 and the change could be adopted by data holders as soon as is practicable.

[NationalAustraliaBank]

NAB supports Option B - Make CRN Optional. For saved biller Payees, we do not save the CRN if the biller supports variable CRN and Option B allows us to exclude this attribute. And for Scheduled Payments & Transactions – CRN is always required to schedule and process a payment hence the response payload will always have a CRN.

We believe adding default values to crnType ( as suggested in option C) will result in data inconsistencies going forward e.g, in a schedule payment or transaction response, if crnType is absent, assuming it is a FIXED CRN will result in incorrect data, as it could be either FIXED or VARIABLE CRN type. As crnType is associated with the official BPAY biller and it is not specific to any data holder, sourcing this data from BPAY directly by the ADRs will be a more consistent way to determine the type of CRN.

[alex-histon]

Newcastle Permanent Building Society supports Option B - Make CRN Optional.

[CDR-API-Stream]

The outcome of this issue has been approved by the Data Standards Chair for inclusion in v1.7.0. A change to the data standards was recommended.

This issue will be closed accordingly.