This is the first part in a three-part technical blog series on bringing COVID Hotspot Alert to market in eight weeks. This focuses on the user experience aspect of the value proposition and how Adatree’s Consent Dashboard APIs that form part of the Accredited Data Recipient platform make the compliance aspects easy to execute. This allows your front-end wizards to work their magic and build rich consumer experiences.
Adatree’s ‘Why’ of COVID Hotspot Alert
First, let’s recap why Adatree, a B2B CDR technology enabler, decided to build and launch COVID Hotspot Alert:
- It fits well with our CDR for Good initiative. Tech companies have lost the trust of consumers and rightly so given the trend of using consumers’ data against them rather than for them. The Consumer Data Right can help restore that trust. And what better way to demonstrate the power of Open Banking data than to provide people with a free tool to help fight a once in one hundred year event.
- To learn more about what our customers have to do when integrating with our Accredited Data Recipient Platform, and how we can make it faster, easier, cheaper, and better.
- To showcase Adatree’s ability to execute quickly and efficiently on a complex service.
The Customer Experience of CDR & COVID Hotspot Alert
One of the biggest challenges that Accredited Data Recipients (and those aspiring) have is the user experience surrounding consent. Adatree provides two options to our customers to help make this easier:
- A white-labeled consent dashboard that’s fully compliant and themable with our customer’s branding.
- A public-facing consent API to allow our customers to build a consent experience of their own into existing applications.
This discusses Option 2, as that is what Adatree did for COVID Hotspot Alert. It was a standalone consumer facing application built on top of our Consent API.
We did this as a standalone app for a few reasons. The main reason being a demonstration of how easy it is to get a fully customised and compliant consent flow up and running using our API.
Another reason was to discover and fix the hard parts of being an Adatree customer by becoming an Adatree customer ourselves. There is nothing like using your own product in the real world to get a feeling for the problems you might be creating for them, and COVID Hotspot Alert was our opportunity to do just that.
We set out a number of rules for ourselves to ensure this was a real effort.
- The first rule was we would build the app on completely different infrastructure to our Accredited Data Recipient Platform. No back doors and no free passes. We would use the same interfaces that our customers use.
- The second was any changes to those interfaces that we required to make COVID Hotspot Alert happen had to be released to our customers, and this actually happened. We made a change to our transaction aggregation API to make querying the data more efficient and it was released to our customers that same day.
Based on this outcome alone, we already consider COVID Hotspot Alert a success because it made our platform better for our customers.
Identity Provider
Adatree’s intention is to fit into your existing offerings and infrastructure. That’s why our consent dashboard and API doesn’t require your customers to create a login just for consenting. Our consent dashboard will integrate with any Open ID Connect compatible Identity Provider. For COVID Hotspot Alert, we used Auth0, but you can use Okta, Keycloak or any OIDC compatible service.
Fig 1. Auth0 mobile login screen
For our APIs, we need an access token from your calling application and a JWKS endpoint where our platform can validate that token. This allows you to bring your existing customers with their existing login credentials to the consent process. From a customer experience point-of-view this is obviously much better, but it will also make your resident information security expert much happier to know that a third party is not managing your customers credentials.
Mobile-First Responsive Web Application for Consent Management
For the consent creation process, COVID Hotspot Alert was built as a mobile-first responsive web application. This was mobile first as the service alerts are sent via SMS so it’s a natural fit. We created a standalone web app for the consent creation flow using the consent API as a base, but then deployed the white-label consent dashboard in management mode only. This means that consumers can log into the management dashboard to view their consent history of expired and revoked consent records but also to revoke current consents.
Fig 2. COVID Hotspot Alert call to action
This allowed us to have a compliant consent management process out of the box and meet our ADR obligations under the CDR, while splitting off the consent grant journey into a concise and completely custom user experience that can fit with the value proposition.
Fig 3. White-label consent management dashboard
CX for Granting Consent
With consent management taken care of, that leaves us with the consent grant process. The COVID Hotspot Alert consent grant web application follows the CX Guidelines for granting of consent as outlined by the CDR Data Standards Body (DSB).
First we present the value proposition to the consumer.
Fig 4. COVID Hotspot Alert value proposition
Followed by the Consumer Data Right explainer.
Fig 5. Consumer Data Right value proposition
We then explain to the consumer how their data will be used.
Fig 6. Explaining how the consumer’s data will be used
We then offer the consumer the chance to choose the bank they want to connect us to. Not all banks are available in CDR yet so we make sure to tell them that to avoid confusion. There are more banks coming online everyday, and Adatree is currently connected to 89 banks in production (as of 9 November).
Fig 7. Choosing their bank
With the bank chosen it’s time to inform the consumer of exactly what data you will be accessing and for what purpose. This may be the most difficult screen to get right in CDR. At the moment data access is split into “data clusters”. If a data cluster gives you access to data you don’t use, you still need to inform the consumer that you will have access to it. This is tricky and can give rise to questions like “If you just need my transaction history, why are you looking at my account balances? What are you doing with that data?”
We’ve worked hard to get the language around this right. It’s important to try and educate the consumer as best you can here. We feel it’s best to be upfront and say, yes we will be able to see this data but we promise we won’t use it because we don’t need to, and that promise is legally binding for us.
Fig 8. Data clusters explained
Adatree is excited that CDR intends to adopt Rich Authorization Requests (RAR) in the future. This is an advanced consent grant implementation where ADRs will be able to package individual pieces of data together to form a custom “data cluster”, and allow the consumer to consent only to that, solving the above problem. For those interested, the draft RAR specification is available here.
Finally, with the consumer fully informed, we present a summary of the action about to take place and ask for explicit consent. Once the consumer consents, we will call the first of our Consent APIs to create the record in the Adatree platform.
Fig 9. Express consent
With express consent taken care of by our UX, there are only three APIs to call in order to complete the consent flow with Adatree.
1. POST consents
Fig 10. Creating a consent record
This creates the consent record in a REQUESTED state in the Adatree platform. The consent will need to be completed at the Data Holder before the consent state becomes ACTIVE.
The consent is created and attached to the Use Case object that has been configured for you by Adatree in our platform. In this case the Use Case is COVID Hotspot Alert. The Adatree platform has the ability to configure multiple use cases and support multiple different front end consent flows for each Use Case. So if you have a use case like lending that is a once off collection arrangement, and a use case like a PFM with an ongoing collection arrangement, then a single Adatree platform deployment can support both with unique customer experiences for both.
2. GET authorization
Fig 11. Getting the redirect URL
This call triggers the pushed authorization request (PAR) to the Data Holder from the Adatree platform and associates it with the previously created consent record. The platform will then generate and return a URL for you to redirect your users to consent with their bank. They will then be greeted by their bank’s consent process.
Fig 12. The bank’s consent process
3. POST tokens
When the consumer successfully consents at their bank, the bank will redirect them back to us. There are a number of URL fragments that the bank sends as part of the redirect. We parse these and then POST them to the tokens endpoint. The Adatree platform will then complete the end-to-end consent flow and cache the access and refresh tokens for later use by the API platform.
Fig 13. Completing the consent process
And with that, consent is complete.
Fig 14. Consent completed
We can now call the Adatree ADR APIs that correspond to the data access that the consumer has consented to.
Next: Technical Detail of ADR Platform Integrations
In the next blog, we’ll go into more technical detail and discuss the integration of the COVID Hotspot Alert backend functions with the Adatree ADR Platform APIs in order to access and process the all important CDR data.
