ANZ and IBM have secured their spots as the first movers in the market to develop a blockchain product to streamline reconciliation between insurers and brokers.
The bank and technology company have released a “proof-of-concept white paper” detailing how the technology works, in a bid to get broader industry buy-in.
The idea behind the technology is that it works alongside the systems insurers and brokers already have, to make what they do more efficient.
Instead of brokers and insurers going back and forth between each other with emails and documents, as customers get quotes, buy products, and renew products, the technology captures the information from their systems and shares it between the parties that need to see it.
Rather than brokers collecting premiums and making bulk payments to insurers, who can have trouble matching payments to policies, the technology can automatically allocate receipts for bulk payments down to the individual policy/invoice level.
Decentralising all the data also means brokers and insurers can access automatically generated reports and analytics.
The way the ‘Hyperledger Fabric’ technology works, each party can only access the information that relates to their own activity.
So an insurer can issue a quote, but can’t accept it, for example. Meanwhile a bank can only see bulk amounts to be paid, not individual policy information.
While ANZ and IBM have developed the product, the nature of the technology means it is completely decentralised, so they too have to play by the rules, and can only access data they are privy to.
At this stage the technology is only being tested with the most simple type of insurance - personal motor - but the idea is to eventually roll it out more broadly.
Suncorp has taken part in the proof of concept. It underwrites the personal motor insurance ANZ sells through its Vero brand.
Yet for the blockchain product to be really valuable, ANZ and IBM need buy-in from all the major insurers and brokers.
ANZ isn’t yet prepared to go into detail around what the financial implications of this are, how the costs will be shared, etc.
In terms of what using the technology would mean for those who work for insurance companies or brokerages, the whitepaper explains there would be a “high level of system integration”.
Yet some smaller brokers might wish not to have their systems integrated to such a great extent.
While there are only a few major general insurers, there are number of different-sized brokerages.
The paper admits integrating the technology is one of the main challenges of “commercial implementation”.
“There are a number of existing systems in place which perform a small part of the puzzle, but the benefit of the distributed ledger solution [product] is bringing together the whole picture,” it says.
“Another benefit often seen with distributed ledgers is the opportunity to digitise assets in the ecosystem, removing the need for paper.
“We see a natural extension for this project to link into customer facing applications owned by the brokers, providing insured parties access to electronic versions of their insurance policies as needed.”
ANZ and IBM say their proof of concept builds on the results a property guarantees blockchain project it has run in Australia.
For more on this and some of the other blockchain work ANZ is doing, see this Double Shot interview interest.co.nz did with the bank’s New Zealand head of transaction banking, Reuben Tucker, earlier in the year.
*This article was first published in our email for paying subscribers early on Monday morning. See here for more details and how to subscribe.
2 Comments
"This mechanism allows us to associate a distinct channel identity (ID) for each broker and insurer with each channel recording transactions separately on its own blockchain. This creates the assurance of privacy, as each party will only be a participant in those blockchains that relate to its own activity."
"A key concern is maintaining confidentiality between the parties involved. This proof of concept considered this, using encryption to protect all data but also implementing channels. These channels result in only the data relevant to that party being sent to them. For example, an insurer will only receive and store information relating to their policies rather than a complete record of all policies. "
So not exactly a truly decentralised system but rather a straightforward multi client based web service which uses encryption (like many of the existing ones today) and different user permissions (like many of the existing ones decades ago). The same issues arise: condensing the different disparate client data into the same structure (many quotes are based on different changing critical data which can be edited at any time prior and after), design of the customised interfaces, managing ongoing payments & policy updates, managing different claims (assuming that this may go beyond sales & into policy management & payments), managing data corrections etc. The ledger is being operated as essentially a versioned encrypted db but with slower access times and less deployment & QA tools. But likely it is about time most of the different provider back ends were updated anyway and rationalised to a single service or had other options to outsource to. Seeing what is used in many companies it is about time some of them joined the 21st century. Much like how SAP, Xero or DPS became competitive by offering services & reporting that streamlined existing operations & integrate with more clients. But still that is an awful lot of bluster for a system that is second verse same as the first.
We welcome your comments below. If you are not already registered, please register to comment.
Remember we welcome robust, respectful and insightful debate. We don't welcome abusive or defamatory comments and will de-register those repeatedly making such comments. Our current comment policy is here.