Token Compliance
In Token Studio we provide the ability for token issuers to define how they want their tokens transferred and specify the types of transfer rules can be upheld. These rules are linked to approved attestations which will be covered in the attestation section.
Rules can be created to enforce sender requirements or receiver requirements for compliant token transfers. Security tokens need transfer rules for compliance and control reasons for example an issuer might need to apply rules to comply with regulation in their jurisdiction.
Within Token Studio the issuer has the ability to get token rules, pause/unpause rules, delete rules, and replace all rules with a new set of rules. In the Token Studio UI created by Polymath, only one token rule with multiple conditions can be created; however, the SDK allows users to create multiple token rules with multiple conditions.
As compliance rules can become relatively complex, figuring out how to provide users with comprehensible feedback on their transaction is something we wanted to focus on. When transactions fail users will get feedback on what compliance rule they need to obey so that they can adjust and complete their transaction.
Using validated identities through CDD (customer due diligence) to manage security token transfers is a great first step to help with the compliance of regulated instruments. But identity is only a supporting feature. What sets Polymesh apart is the approach that simplifies compliance for issuers by using identity verification through CDD as a cornerstone.
If you used Token Studio on Ethereum, you’d have noticed our whitelisting feature where users upload a list of approved Ethereum addresses that may receive or send your token. Creating a list of all potential recipients and holders of your security token is time-consuming and inefficient at best, and impossible at worst. Unfortunately, this is the standard within the security token space. Polymesh changes that with a Token Studio that supports a far more effective approach, allowing users to set the characteristics of who can hold and transfer their security tokens rather than by trying to identify each holder. This is done by setting claims-based token rules and then attaching claims to user identities that will be checked each time a user tries to send or receive your security token.
If you need further information on rules please refer to the API documentation below.
