Project Description
CLIENT PROFILE
Our client is a fast-growing non-captive automotive bank with several thousand clients, both dealerships and consumers, and various innovative product solutions.
| Industry | Financial Services |
| Employees | 201-500 |
| Year founded | 2011 |
| Publicly listed | No |
CHALLENGE
We had to tokenize ownership certificates, however, both infrastructure and process had to be developed first as the property was not listed in a global digital register yet, hence, the register had to be built first.
PROCESS
The project was structured into three distinct steps:
1. WORKSHOPThe workshop covered several aspects before we moved from discovery to the design phase:
|
|---|
2. FEASIBILITYWe conducted a detailed feasibility report prior to taking stock on all relevant software requirement specifications:
|
|---|
3. POCOnce all milestones, deliverables, timeline and the budget were agreed upon, we kicked-off the implementation of the Proof-of-Concept:
|
|---|
SOLUTION
We used the TokenD framework, specifically built for the purpose of tokenizing real-world assets, to design a secure and scalable distributed ledger with a built-in reliable consensus mechanism that allows ownership transfer of the tokenized assets.
RESULTS
The client can transfer vehicle ownership in a secure, fast and reliable manner through the distributed ledger solution. Automated vehicle transfer and registration between businesses and consumers will be possible once the government's public registry for vehicles goes live in Q1/2020.
DETAILS
Click on the toggles to find out more about the specific project details:
The goal was to develop a DLT-based platform tokenization core with the objective to provide the following functionality:
- Secure and scalable distributed ledger with built-in reliable consensus mechanism
- User accounts lifecycle management
- Deposit operations management
- Withdrawal operations management
- Tokens issuance management
- Tokens properties management
- Tokens turnover management
- Transactions fees management
- Transactions limits management
- Web wallets
- Mobile wallets
- Internal exchange module
In order to achieve that, the clients intended system actors had to be defined first, while we differentiated between management and non-management actor roles.
Management actors
The management actors are involved in user creation, token creation & management and processes management. For our purpose, we defined the following management roles: super admin, KYC administrator, fees administrator, limits administrator, trade administrator, security administrator, pre-issuance and issuance administrator.
Non-management actors
Besides systems-side users, we differentiate several non-management users: unverified user – users that did not perform the KYC process and cannot trade any assets on the platform, verified users – users that performed the KYC process and are allowed to participate in an asset transfer and corporate user – a platform user with a company account that is validated as a company and can act as the creator of an asset or invest in existing assets.
After several top-management workshops we narrowed down the core functionality that needs to be provided:
- Secure and scalable distributed ledger with built-in reliable consensus mechanism
- Ledger viewer
- User accounts lifecycle management:
- Unverified users account registration, account login/logout, account ban and recovery
- Verified users account registration, account login/logout, KYC management, ban and recovery
- Corporate users account registration, login/logout, KYC management, ban and recovery
- Deposit operations management without autoconversion: deposit of fiat currencies, deposit of cryptocurrencies
- Withdrawal operations management: withdrawal of fiat currencies & cryptocurrencies
- Tokens lifecycle management: secure token-to-collateral ratio accounting and management: Tokens pre-issuance & issuance management, Business logic imposition for each type of tokens, Tokens sale to users for fiat currencies, Tokens sale to users for cryptocurrencies, P2P transfers between users' accounts on the platform
- Transactions fees management: fees imposed on token payment, account type, specific account, flat fees, percentage fees
- Transactions limits management: limits imposed on a token payment, account type, users' KYC/AML information, on specific account
- Web wallets: for unverified users, for verified users, for corporate users
- Mobile wallets: for unverified users, for verified users, for corporate users
- Internal exchange module
To allow for a seamless customer journey, several interfaces are deemed minimum required:
- User's dashboard & wallet
- Admin creation
- Fees management
Additionally, there are several other requirements that have to be met:
- Performance: up to 100 transactions per second / up to 500 transactions per block; for 90 percentile of valid payment operations over 1 hour period, the system will apply payment operation in no more than 15 seconds, during system load of 200,000 payment operation per hour with uniform distribution over that hour, (under no circumstances this operation to take longer than 30 seconds) to be performed in network of 4 fully connected instances with following characteristics: AWS m4.xlarge (4 vCPU, 16 GiB of RAM, SSD storage) deployed in the same region.
- Security: the system does not store non-encrypted user secrets and uses secure connections to transfer data outside of firewalls; users are automatically logged out after a period of inactivity; no user/admin secrets are in local storage of the browser; all asset related transactions require confirmation; user’s KYC documents are not stored non-encrypted; encryption keys and encrypted data is not stored on the same server and does not depend on the same instances of services; no information regarding balance or transaction history to any third party but the admin is provided; all the changes to an account are traceable; the system prevents double spend by design; no unauthorized operations are performed on an account;
- Software quality: reliability - probability of getting system error (assuming that hardware and input are free of errors) should be 1% or less; recoverability - it should be possible to fully recover the system with data loss of 24 hours at max (data related to finance and access rights should be fully recoverable without any data loss)
- Data storage: all critical data, such as users private keys and users KYC data must be strongly encrypted; strong encryption is defined as cryptography based on industry-tested and accepted algorithms; private data must be encrypted on client side and encryption key must be provided by the user (user email and password); KYC data (as it should be accessible by owners of this data as well as corresponding administrators of the system must be encrypted with shared keys, which must be stored on separate server
- Integration & testing: The system will be fully deployed in the cloud (AWS), so the reliability of hardware will be fully handled by Amazon.
- APIs & SDKs
