Our issues with the Open Banking Product API
On the face of it, the Open Banking Product (OB) API is a great idea. Every banks product data in the public domain using a common and computer-friendly format updated in a timely fashion. However, like any standards implementation, the devil is in the details. It goes without saying that an API Standard must be usable by the intended audience for it's intended purpose. If the purpose is for parties to be able to download bank product information in a computer-friendly format to massage and display to consumers then the complete information must be available. The following is our list of issues that we feel deviate from this purpose.
Note: Since we are in Australia, we are going by the Consumer Data Rights.
Lack of data totality
There is nothing in the Standard that states a required minimum data-set. The Standard states that it is a complicated task to define a Standard which can encompass the vast range of financial product options, and we agree in principle but certainly not in implementation. The Standard thus allows the bank to include URLs which point to the bank's own webpages (via the AdditionInfoURI field) which contain the information not within the API results. In fact, there is no reason why a bank, to be compliant, could not just post the Product Name, Product ID, and an URL back to a page on the bank's website.
Obviously the more information is left-out, the more useless the service becomes since it means that either the missing product information is not displayed to the consumer, or the 3rd-party must find the URL of the missing information and scrape the pages in order to display the total product data to the consumer. And scraping a web-page is, at most times, not an easy exercise and is actually disallowed by most websites.
A major piece of information for a mortgage product is maxLVR (Loan Value Ratio), which is the ratio between loan amount and the security value. Typically banks will be hesitant to lend at 90% or above. Banks use mortgage insurers (MIs) such as Genworth/QBE here in Australia to insure mortgages so the rules on maxLVR and the restrictions on postal code, residence type, etc. are solely due to the policies of the MIs.
For mortgage brokers, maxLVR restrictions are a very important part of their client work since brokers rarely get a client who has a (say) $200,000 deposit on a $600,000 house. Clients like this would probably just go to their usual bank for a mortgage. Brokers usually work with high-LVR clients who may only have 1 or 2 banks that will ultimately lend them their required amount.
We contacted a major bank asking if they will be providing maxLVR information as part of the Product API and they replied that there are no plans to do so. We do understand their reluctance considering that the maxLVR data is not their own. However, the data supplied by the OB APIs should be equivalent to if I went to a bank branch to ask about their particular product; the branch would give me all the product data including maxLVRs, maxLoans, etc.
Earlier we stated that we agree in principle that it is difficult to create a Standard which can accommodate the full breadth of financial product options, but it is doable to a point. The maxLVR, maxLoan data could be listed within the Constraints section as least to the point where it is consistent with the information available on the websites. Of course, it would be a Herculean effort to add all constraints but if the websites and bank branches have it, the OB information should have it.
So the question is: How are users of OB Product data supposed to display the totality of the Product to the consumer, or to use OB Product Data in aggregate comparison calculations?
Lack of SLAs
Under the 'Data Quality' section of the Standard, the only stipulation is that the data provider must take reasonable steps to ensure that the Product data is accurate and up-to-date.
This vague, blue-sky requirement is poison to a 3rd-party user who will provide services to consumers based on the OB data. Banks will only act based on the extent of the regulations; if the regulations are vague or ambiguous, then so will their efforts.
This lack of hard SLA's returns to the marketplace the same issues which plague(d) the mortgage broker industry. The banks did not support the broker market even when their share of the loan market grew past 50% of all mortgages. Consequently, the product data used by the brokers for comparisons/etc could never be guaranteed to be correct. This was/is a terrible plight on the broker industry and resulted in many cases of legal action or at the very least, one fuming never-to-use-another-broker-in-my-life client.
The stipulation in the Standard should be that the product data in the OB APIs must be updated when the bank updates it's own web-pages. Or, at least, when the changes to the product are disseminated to the bank's internal staff/branches.
These types of hard requirements must be in the Standard because what recourse is there for any 3rd-party API user otherwise. Currently, if a 3rd-party contacts the government Financial Ombudsman for incorrect data then the bank can make any case under the fuzzy guise of 'reasonableness'.
The lastUpdated field
The lastUpdated field will be quite important as 3rd-party API users will, most likely, setup automated nightly runs to seek the products that have changed that day. The question is: what 'updates' change this date? For example, say that some of the fee/pricing data is missing, and the Product API links to a web-page using the 'feesAndPricingUri' field. If this particular web-page changes, does that also change the lastUpdated field in the Product data? We suspect that it won't because, well, it's not in the Standard.
If not, then this greatly diminishes the usefulness of the lastUpdated field to the point where it is somewhat meaningless.
Past products will be deleted
The Standard says a linkage between an customer account and a product will not be provided; and that deprecated products will be removed. Why? This information can be extremely useful.
It would be invaluable to determine and display how the competitiveness of a product changed over time. Or how a particular product became non-competitive and what changes, either the product itself or consumer circumstances, caused this shift.
For example, it would be very valuable as a marketing tool to use the OB API to show a consumer how banks change their rates based on central bank rate changes. Some banks change very slowly, some don't pass-on the complete rate reduction but will increase their own rates by the full central bank rate. This can show a pattern of behaviour from certain banks.
In Australia, mortgage brokers need to show the client that a particular product meets their requirements. But in a refinance situation, how can a broker completely understand their circumstances if they do not exactly know the loan product to be refinanced? Having the ability to go back to this product and see the entire product parameters at the time of loan approval would allow the broker to be fully compliant with the duty-of-care regulations in refinance cases.
And we fail to see how this would impact performance. The Products API would change to include an effective date query parameter to return the product at that particular time. The absence of this parameter would default operation to what it is now.
Are Mortgage Insurers coming on to Open Banking?
This is a question based on the maxLVR issue described above. If they are, then all product data would be available from the API. The bank would detail the MI that they are using (probably using the AdditionalInfo field. The 3rd-party API user would then parse the bank JSON Product Data, and then call the APIs from the MI in order to obtain the maxLVR, maxLoan, etc information which would complete the product data.
solutions for open banking monetization
ReplyDeletePersonalize products, offers, pricing and loyalty programs; prevent revenue leakage and ensure regulatory compliance with a billing solution.