A Self-Sovereign Identity approach to identify fraudulent bank calls and speed up banking services (Part 2)

8 min readAug 16, 2019

This is an extension to my previous article “A Self-Sovereign Identity approach to identify fraudulent bank calls and speed up banking services (Part 1)”, where I listed down pain points faced by customers in identifying fraudulent bank calls and challenges faced by banks in validating customer identities.

In this article, I will discuss on relevant use cases and how SSI (Self Sovereign Identity) fits into the exiting bank service flows)

Relevant Use cases and How Self-Sovereign Identity model fits into the existing flows

Let’s get into the context of our use case — Identify fraudulent bank calls and speed up banking services

Concept of Self Sovereign Identity can be applied to any financial service flows (Loan Approval, Payments, account updates, etc.) which involves sharing an identity. In this article, I would like to touch on the following use case

Inbound promotional call from a sales executive to the customer to promote a personal loan

Best Scenario (The way how it works currently)

Customer (Bob) holds an account with Bank
Third-Party Agency (let’s call Trusted Agency) is authorized by the bank to call Bob to promote loan (Explain loan offerings, EMI, Interest, Preclosure details, etc.)
Bob Receives a call from Trusted Agency
Trusted Agency asks Bob to share some of the details to make sure that they are talking to Bob and Bob hold an account with the bank such as name, date of birth, employment status, salary, residence address, etc
Trusted Agency will answer all of Bob’s queries
If Bob Agrees to avail this loan, Trusted agency forward request to the bank
Bank will call Bob again, connects to an automated machine to validate credentials. In some cases, Bank might ask Bob to submit Identity proof, employment proof, etc for KYC Process
If everything works Ok, the bank will approve the loan

Bad Scenario with fraudster acting as Agency (Lets call as Fraud Agency) (The way how it works currently)

Bob Receives a call from an agency (Fraud Agency)
Fraud Agency asks bob to share some of the details for validation
Bob discloses all the information
In some cases, fraud agency can also pretend to be a bank and steal confidential banking information

There are two major drawbacks in these scenarios

(No Identity Check) — Bob doesn’t really know whom he speaks to
(Information Leak: Bob discloses more information than what is required). Here, Trusted Agency/Bank is looking for a way to make sure the person whom they speak to is Bob and he holds a valid account with Yes Bank)

Redesign above flows using SSI (Self Sovereign Identity)

Before I start, Let me illustrate how verifiable credentials & verifiable presentations (claims & presentations in this article are used interchangeably) look and how are they transferred from issuer to holder

Bank issues a verifiable credential to Trusted Agency authorizing them to contact customers from mutually agreed phone numbers and promote bank’s loan offerings

Verifiable credential issued by the bank to Trusted Agency

Bank creates a credential, signs with its private key and issues to Trust Agency
Bank also stores metadata of this credential on blockchain
Trusted Agency receives this credential and stores it into its wallet
Public Keys are either stored on a blockchain or stored off-chain with a reference in blockchain

Bank issues verifiable credential to Bob’s wallet on his mobile phone. Bob can choose to disclose what information to be shared to the verifier, in this case, Trusted Agency

Bank issues verifiable credential to Bob certifying his account with the bank
If Trusted Agency asks to prove that he owns an account with the bank, Bob chooses to disclose some of the fields (in this case Bob chooses to hide the date of birth and address), signs with his private key and shares following details to Trust Agency as Verifiable presentation
Verifier (in this case Trusted Agency) will perform some cryptographic validations and validates Bob.

Let’s move on redesigning the flow using SSI

Bank issues a verifiable credential to Trusted Agency authorizing them to contact customers from mutually agreed set of phone numbers and promote their loan offerings
Bob holds an account with Bank and bank issues verifiable credential to Bob’s wallet on his mobile phone. Bob can choose to disclose what information to be shared to the verifier
Bob has also received credentials from Government (Identity Proof -Social Security Number), Proof of Employment (from current employer)
Bob Receives a call from Trusted Agency
Trusted Agency initiates “Identity Check”. Identity Check is intended to make sure both parties validate identities

Identity check involves Bob sharing bank account ownership credential to Trusted Agency and Agency sharing Authorization Credential (Credential receives from the bank) to Bob.
Bob will only disclose a subset of information from his credentials to prove that he owns a bank account with the bank

Optionally, an Event-based Smart Contract can be executed between Telecom Operator and Trusted Agency. During Identity Check, Mobile Operator will validate Trusted Agency phone number and shares claim (Certifying Trusted agency own the telephone number ) to Bob

On Successful Identity Check, the Trusted agency goes ahead and shares Personalized loan options to Bob
If Bob Agrees to avail this loan, Trusted agency forward request to Bank
Bank will initiate Identity check with Bob again
Bob creates verifiable presentation combing various credentials received from (Government, Bank, employer) and shares to the bank. Here Bob chooses to share a different set of information from same credentials than what was shared to Trusted Agency.

Name

Account Number (From Bank)
Date of Birth (From Passport)
Current Address (From Valid Drivers License issued by DMV)
Current Employer (Credential issued by Employer)
Salary (Credential issued by Employer)
Consent for Loan (Self-signed credential)

Bank validates Bob’s verifiable presentation and will approve/decline loan to Bob

Architecture

I tried to classify what is required for this solution into three different layers.

Layer 1 (Blockchain Network)

This layer forms the basic building block of the solution and will be used to achieve decentralization. There are many solutions that are actively developed. Blockchain networks such as Sovrin, Veres One are specifically built for Identity, whereas other networks such as Bitcoin, Ethereum, IOTA are generic blockchain networks and require additional layers on top of an existing system to incorporate identity information into the network

Layer 2 (Decentralized Identity Stack)

This layer creates basic building blocks and tools to achieve Self-Sovereign Identity

Decentralized Identifiers — By Simple definition, DIDs propose is to use blockchain to register identifiers that users can use to identify themselves. W3C is working on to standardize DID’s. Reference
DKMS — Decentralized Key Management System is a new approach to cryptographic key management intended for use with blockchain and distributed ledger technologies (DLTs) where there are no centralized authorities. More details here
Verifiable Credentials Management — This involves management and validation of credentials, claims, and presentations that are shared across different stakeholders (Issuers, Holders & Verifiers). W3C Verifiable Claims group is working on creating these standards. Reference
Identity Wallets — to store and manage cryptographic keys, credentials, and relationships with different entities. Here is a good report on “The Current and Future State of Digital Wallets” by Darrell O’Donnell, P.Eng of Continuum Loop.

Layer 3 ( Enterprise Decentralized Identity Controller)

One of the missing pieces that I see missing in layer 2 is a glue layer which should orchestrate decentralized flows based on the rules set by different participants in the network. I envisage an additional layer (Layer3) to be built on top of layer 2, somewhat equivalent to MuleSoft for the decentralized world to connect centralized legacy identity management systems to the world of decentralized identities. This is more of a generalized design that can be adapted to any use case.

Key functionalities this layer should include are

Value-Added Services — Services that can assist customers in managing their identity wallets. For example, in the current use case, I can think of multiple services

Telecom Operator certifying a mobile number
Customer doesn’t have an efficient way to validate agency number. An Event-based smart contract can be executed between Telecom operator and Trust Agency that would certify ownership of the incoming mobile number (In our use case, Trusted agency number) dynamically and present to a customer during the call.
Voice enabled Identity assistants
A cognitive Agent at Edge wallet that would automatically present required credentials on behalf of the customer based on whom it interacts with.

Integrations with Legacy Identity systems — Connectors that would allow existing legacy Identity management systems to integrate with decentralized Identity systems. This is an absolute for enterprises with legacy identity management systems and would like to shift to decentralized identity stack with reduced costs.

SeLF allows you to integrate the Self-Sovereign Identity into your infrastructure without modifying your legacy IT-applications, directories or management systems. SSI credential-based access rules (CrBAC) transform the new technology into authentication and authorization objects that can be synchronized and used by conventional technologies like SAML or LDAP.

Orchestration & Business flows — Defines and orchestrate business flows that utilize decentralized identity components (Layer 2)
Reputation & Trust hubs — ubiquitous trust layer that enables users to assess trustworthiness across applications. These systems are extremely important to establish trust across different unrelated parties in the system.

Conclusion

I hope this post was useful in giving you a big-picture on how self-sovereign identity could prevent fraudulent bank calls and establish a trust relationship across all stakeholders.

Architecture that I illustrated here is more of a generic that can be applied to different use cases that involve decentralized identity. I didn’t elaborate much on the architecture especially on Layer 3 and I will follow up with a much more detailed architecture with relevant POC’s as my work progresses.

Disclosure: I am neither a banking expert nor understands the inherent security measures/procedure adopted at banks and call centers.

Don’t hesitate to correct any mistakes I’ve made or start a (healthy) discussion in the comments.

References

1. SSIMeetup Webinars

2. Sovrin

3. W3C Verifiable Claims Use Cases

4. W3C Verifiable Credentials Data Model 1.0

5. The Three Models of Digital Identity Relationships by Timothy Ruff