Architecture of Tokenization
IT Architecture Scheme
Key players of our IT architecture:
- Product Owner — a company that creates various fintech products. In the future it will become something more — both the company and the community that create product technologies together.
- It’s a Solution Provider, Product Provider and finally Technology Provider. Mainly it is a company that owns the technology of Smart Asset creation based on the Blockchain Service Architecture and it creates new types of Smart Assets for the Originator.
- The Product Catalogue holds a central place in our IT architecture.
- Product Owners are the ones populating the Product Catalogue.
After examining the entity of the Product Owner, we understand that the Proof-of-Asset Protocol is able to realize a multitude of product solutions and Product Instances depending on application, location and legal conditions. The number of Product Instances is not limited, so to introduce the Product in a new country or account for a change in current legal conditions, the Product Owner needs only update the Smart Asset formulas and releases a new Product Instance.
With time a large number of Product Instances will form for every Smart Asset Type and this number will form a product catalogue that the protocol’s ecosystem will interact with. The BANKEX team calls this the “Smart Asset Catalog”.
This schematic has two “wings” detailing interaction with an asset. The reason for this structure is to make it easy to understand, that it doesn’t matter which side represents the originator and supplier. Both are tokenized using a completely identical schematic in terms of IT architecture, but whether the originator and supplier is a bank or a non-bank it makes a big difference for the IT architecture.
If it is a non-bank, then tokenization is performed without using the Microsoft Azure Bank API. But if the originator/supplier is a bank, then tokenization gains an additional contour – the Microsoft Azure Bank API.
Azure Bank API is a comprehensive set of cloud services that developers and IT professionals use to build, deploy, and manage applications through our global network of datacenters.
It was developed by Microsoft Azure specifically to work with banks. It takes into account bank certificate compliance, regulation compliance and so on. But since Microsoft Azure it essentially a cloud, a bank can only use it as an external internet-service, which complicates actual use of this service. Which is why currently Azure are working on a local cloud that contains all the services of regular Azure, while technically manifesting as an installation that, generally speaking, is placed in the bank.
This lends a number of advantages: On the one hand, it is located in the bank, within the border of its IT security. On the other hand, it is compliant to all product solutions present in Microsoft Azure, which allows it to be quickly deployed with ease. We are able to become one of the products as part of the Microsoft Azure Bank API, which is a significant advantage. It’s also important to note that Microsoft Azure is a cross-platform solution, meaning it allows for deployment of technologies other than Microsoft technologies.
This represents a large change for Microsoft from an enclosed ecosystem to an open source software solution. Which is the key difference lending a significant advantage over other blockchain projects.
Azure Active Directory is a IaaS (identity-as-a-service) which currently provides and manages access of BANKEX team to services that are currently available on Microsoft Azure. Storage Account is a durable, robust and scalable storage solution which allows us to store all the essences that are deployed within our solution.
As an open, flexible, and scalable platform, Azure supports a rapidly growing number of distributed ledger technologies that address specific business and technical requirements for security, performance, and operational processes.