Skip to main content

KYC Example App

After learning about the SDK elements that work for KYC, let's have a look at a simplified example of what it would take to integrate an existing system with Polymesh. For this example, we will consider the case of EzKyc, a company that provides KYC services. Actually, EzKyc provides a very simple service, it provides an opinion about the validity of the documents provided by the customer to justify as being under a certain jurisdiction. In the same way we did for the settlement example app, to simplify, and not overburden the reader with elements not relevant to learning about Polymesh, we did not add any authentication nor authorisation mechanism.

Pre Polymesh

Let's describe the EzKyc system before we integrate it with Polymesh.

The setup

2 pages are served:

There is a rudimentary server that exposes a simple API:

  • api/kycCustomer/[id].ts, the end point to get, put and patch customer information. Following the absence of login, it is used by both the customer and EzKyc.

On the server, a single service is running:

  • customerDbFs.ts, a service to customers' information on disk in a large JSON file, instead of a proper database, for simplicity's stake.

The system describes its information in terms of:

  • CustomerInfo, an object that collects both the customer-provided information and EzKyc's decision.

How it looks

When a customer of EzKyc logs in on /index, using their customer id, they enter all their relevant information. Of course, since there is no authentication in this simplified example, anyone can use any id:

Customer information

At a later stage, on /manager, someone from EzKyc will review the information and mark the information as accepted or rejected depending on the case:

Customer approved

Back to the customer view, when the information has been accepted, it is no longer possible to modify it:

Information locked

Post Polymesh

Time to integrate with Polymesh. What needs to be done?

The setup

Let's go from the bottom up.

On the configuration:

On objects:

On services:

  • customerDbFs.ts does not have any change. There could have been a check on the Polymesh id of the customer.

On the API end points:

  • api/kycCustomer/[id].ts publishes an attestation when the customer is validated by EzKyc and the customer has a Polymesh id, whichever happens last.
  • api/kycProvider.ts exposes the Polymesh DID of EzKyc so the customer can check on their own whether the attestation has been published.

On pages:

How it looks

There is more information to provide when submitting a buy order, and after the customer sends their Polymesh id, the attestation is published:

Attestation present

From EzKyc point of view, the only extra is the customer's Polymesh id:

Result EzKyc


That's what it takes.

  • Make your server able to access Polymesh.
  • Store a bit more information in your database.
  • Make your server able to publish attestions when relevant.
  • Make your Web pages a bit more decentralised by having them fetch themselves the attestation.