CDR-API-Stream
commented
3 years ago Hi @DimitriSty, thanks for the detailed response. The Payload Conventions section of the Consumer Data Standards covers the requirements around Optional vs Mandatory vs Conditional fields. Optional fields do not mean that the Data Holder may optionally chose to implement them. If the Data Holder holds the data it must be provided. Specifically:
Note that for optional fields are not considered optionally implementable by a Data Holder. For instance, if a Data Holder holds data in digital form for a Customer that is represented in a payload then it is expected that this data will be shared when authorised by the Customer. For payloads unrelated to Customers, such as product reference data, there is more discretion for the Data Holder but other drivers, such as complementary regulation or the requirement to align to other channels, should be taken into consideration.
This means that data held by the data holder that relates to the consumer must be shared but as you point out some products or transactions etc, may not have the data in all instances. In these cases, making the fields Mandatory would not be suitable.
For public unauthenticated data like PRD, data holders must observe their obligations under any other complementary regulations. PRD is effectively a digital version of a product disclosure statement and banks are required to provide all fees and conditions related to products - just because a field for fees is Optional does not mean a data holder can exclude them if they apply to the product.
Xero is concerned about the overall impact of the large volume of optional fields in the schema as we believe they will significantly reduce the customer value provided by CDR. The approach to optional fields seems to have been to mark any fields that might ever be unavailable as ‘optional’ which makes for a simpler, easier to understand structure but has some unintended consequences that we will discuss in more detail.
Examples An easy to understand example appears in the BankingScheduledPaymentRecurrence schema where the nextPaymentDate value is optional. We understand that this is likely to be a calculated field in some banking systems and hence not a value that is guaranteed to be available all of the time. However, stepping back, a customer who opts to share their scheduled payment data would have a very reasonable expectation that this data would always be shared if it was available. Not having the nextPaymentDate available would mean customers would have to manually enter the information, wasting time, introducing manual errors and devaluing the provision of data through CDR for them.
A similar situation occurs in the BankingProductLendingRate schema where the comparisonRate is optional. We understand that this rate may not logically apply to some products, however where it does apply it is essential information that customers will reasonably expect to be available when they consent to sharing this data. The lack of a comparison rate would limit the value of services that could be provided to customers around a true understanding of the cost of their lending. The same consideration applies to values in the Banking Transaction schemas - notably merchantName, merchantCategoryCode, billerCode, crn, and apcaNumber. The first field and second field mentioned above (where available, typically in credit card transactions) are used by software companies to reconcile transactions to GL accounts. Making this data optional reduces the utility of the data to only support transaction processing, rather than the management of processes that businesses need to go through post transaction.
An additional example occurs in the BankingPayee schema where the description and creationDate are optional. This is key information used by customers to identify their payees, and if they have this data available in their banking system it is quite reasonable to expect it to be available when they consent to share their data. In practice it is likely to just lead to duplication of effort for customers - they enter a payee description in their online banking, they share their data and then enter the same description into Xero and every other application that they have shared with.
A final example is the currency field in the BankingTransaction schema which is optional but assumes AUD if no data is provided. This is interesting because it is an absolutely basic part of a transaction, and all banks will deal with multiple currencies in one way or another. We understand that banks may not apply an AUD currency label to some transactions as a matter of course, however making this optional means that every single consumer in the ecosystem will have to build code to work around this. If this field was mandatory the data would be provided in the source system for all consumers present and future. As it is, it is an ongoing cost of participation in exchange for saving banks from a minor inconvenience.
Impact The net effect of these choices on customers is to reduce the usefulness of CDR and generate manual effort where there was none before. From a data consumer perspective this will stifle innovation as companies need to be able to rely on data being available to harness it and innovate. If data is only available some of the time that increases the cost to develop as you have to build handling for both when the data is and is not available. Standards are the lever used to promote innovation, but the value is in having certainty about the data you have access to - all uncertainty reduces value and reduces innovation.
As some of these sharing arrangements have been in place for a number of years under a bilateral model, the data sets that are mandatory should, where available, match the current sets. Xero’s position has consistently held that the CDR will be successful if the customer experience, driven by the data, is the same or ideally better than current. Without this it makes it difficult to support moving under the CDR regime.
Proposal What we propose is making these fields ‘Mandatory if available’, along with a review to understand if additional fields meet the same criteria. In addition, for reasons explained above the currency field for transactions should be made mandatory.