Shaping the future of banking and financial services in Hong Kong: A Docusign primer for developers, Part 2

By Charlie Loo, Principal Solution Consultant, Docusign

Developers who build banking applications love to work with platforms that are fast to set up, easy to use and have clear documentation to help accelerate development cycles and meet deadlines. In this series of blog articles, I’ll show you how Docusign delivers — specifically, for a common use case in the banking and financial services sector. This is the second of three blogs.  

In the last blog post in this series, we explored how and why a bank would want to digitise the account opening process; and explained the various types of OAuth 2.0 authentication, and how to authenticate and send a Docusign envelope in a few simple steps.

Now, let’s take things a step further. In today’s blog, I’ll be showing you how developers within banks can use the Docusign API to verify a signer’s identity during the signing ceremony.   

Traditionally, customers would have to visit a bank branch to open an account. They would queue up, approach the bank teller, fill in an application form, and show some sort of photo ID (e.g. HKID) to verify their identity. The teller would then have to manually verify all the information on the form; while the customer would have to remove their face mask, hat, or any other coverings so the teller could visually match their face to their photo. Only then could they accept the signature on the agreement.

Today, banks in Hong Kong take a much more modern approach. The Bank of China (Hong Kong) was a trailblazer in the digital ID verification space, being the first bank in Hong Kong to put ‘iAM Smart’ technology to work. This technology is a real time-saver for banks and customers, as authentication can happen digitally instead of face-to-face.

But what if the customer doesn’t have ‘iAM Smart’ or another form of digital ID token?

Docusign’s next-level ID verification services

At Docusign, we use ID verification to help senders verify recipients’ identities with passports or government-issued ID cards, answering security questions, or using electronic IDs or bank logins. In most cases, this is sufficient. Yet given the increasing volume of fraud and identity theft in recent years, we asked ourselves, how could we level-up?

To make our ID verification solution even more secure, we introduced Docusign’s Liveness Detection.

Layered on top of digital ID verification, our liveness detection technology deters identity spoofing by executing biometrics validation during the verification process. It compares the photo on the signer’s identity document against a selfie video taken as part of the verification process. The experience is powered by AI, making it faster and easier to confirm the identity of the signer remotely.

How do you invoke Liveness Detection from the Docusign API?

To add ID verification with Liveness Detection to your account opening journey, you start with the same steps as we outlined in the previous blog, and then add an additional attribute “identityVerification” in the JSON payload.

POST /restapi/v2.1/accounts/<your-account-ID>/envelopes HTTP/1.1

Content-Type: application/json

Authorization: Bearer <your-access-token>

Host: demo.docusign.net

User-Agent: RapidAPI/4.2.5 (Macintosh; OS X/14.5.0) HTTPRequest

Content-Length: 41842

{

  "emailSubject": "Sales Agreement for George Lam",

  "documents": [...],

  "recipients": {

    "signers": [

      {

        "email": "george@test.co",

        "name": "George Lam",

        "recipientId": "1",

        "identityVerification": {

          "workflowId": "XXXX-2222-XXXX-4444-11XXXXXX5566",

          "steps": null

        }

      }

    ]

  },

  "status": "sent"

}

This instructs Docusign to initiate an ID verification for that signer. In the example above, the workflow has an ID of “XXXX-2222-XXXX-4444-11XXXXXX5566”.

The next step is to access this workflow. And it’s simple to do — we ask for it! More specifically, we make a query.

GET /restapi/v2.1/accounts/<your-account-ID>/identity_verification HTTP/1.1

Content-Type: application/json

Authorization: Bearer <your-access-token>

Host: demo.docusign.net

User-Agent: RapidAPI/4.2.5 (Macintosh; OS X/14.5.0) HTTPRequest

If your Docusign account is enabled with the ID verification service, the query will return the following JSON response.

{

  "identityVerification": [

    {

      "workflowId": "XXXX-2222-XXXX-4444-11XXXXXX5566",

      "workflowLabel": "IDV With Liveness",

      "defaultName": "Docusign ID Verification with Liveness",

      "defaultDescription": "recipient will identify with a valid government ID and a video selfie",

      "workflowResourceKey": "idv_with_liveness",

      "steps": [ { "type": "EnvelopeAccess" } ],

      "signatureProvider": null

    }

  ]

}

Use the workflow ID belonging to the workflow “Docusign ID Verification with Liveness” and you’re good to go.

Once the above steps are complete, it’s then easy for developers to build conditional logic around the application workflow based on use cases and business logic, which determine if a signer would need to have their identity verified before being allowed to review and sign an agreement.

With Docusign ID Verification with Liveness in place, banks gain the assurance of one extra step of security during the account opening process — helping to mitigate the risk of fraud while streamlining the customer experience. It’s a win-win.

Watch out for the final article in this series, where I show you how to generate agreements on the fly, a great way to automate and save time across the banking system.