Building Compliance into Digital Securities
Updated: Mar 4
by Abhi Jayakumar, Product Manager, TokenSoft
It’s an ever-exciting time to be launching a digital security. The list of potential advantages includes global liquidity, 24/7 access, fractional ownership, and peer-to-peer trading. With all that opportunity comes increased responsibility when it comes to compliance. After all, digital securities require compliance with the same regulations as traditional securities in both the initial issuance and secondary trading stages.
In our experience, one piece of the digital security offering puzzle that is often overlooked is how to build compliance into the construction of the security that can adapt and adjust to an ever-changing regulatory environment. Often projects take approaches that cause downstream challenges for their investors because they did not plan for the ongoing compliance requirements early on in the design process.
At TokenSoft, we are privileged to be involved in these early design conversations and create bespoke compliance solutions that help token issuers comply with securities laws throughout the token issuance and post-sale phases.
Instead of talking generally about common considerations, let’s talk specifically about what we’ve heard over and over again.
While the compliance requirements for a digital security will vary based on the circumstances and jurisdictions, there are two regulatory topics on which we provide guidance to our clients the most: Flowback Prevention and meeting the Bank Secrecy Act requirements.
The Bank Secrecy Act (“BSA”) requires financial institutions in the US to assist US government agencies in detecting and preventing money laundering and terrorist financing.
The BSA requires financial institutions to have anti-money laundering procedures and a customer identification program, which commonly translates to Know Your Customer (KYC) checks.
The whole idea is to know who you are taking money from when transacting. This is standard practice across financial institutions and applies to digital securities as well.
In the blockchain world, the treatment translates to tying the identity of an investor to their blockchain address.
Flowback prevention is the idea of separating US investors from international investors to prevent tokens held by non-US investors from flowing back to US investors.
With the sale of equity securities by a non-reporting company outside of the US, the lockup period relating to sales to US persons is the same as with securities sold within the US (12 months).
While their lockups are in effect, it’s necessary for the issuer to prevent non-US investors from selling tokens to US investors.
With all of this in mind, the challenge we’ve looked to solve is how to design a digital security token with full-lifecycle compliance already baked in and that doesn’t put up unnecessary hurdles for issuers or their investors.
Solving for Compliance Requirements
In order to address these challenges, we created the ERC-1404 smart contract standard, which solves for the compliance challenges that are part of the issuance process and beyond. If you want to go dig into the details, please visit erc1404.org ERC-1404 site. Here’s a quick primer:
An ERC-1404 token is basically an ERC20 token with a couple of restrictions added.
The base two checks are: Can Send and Can Receive.
This forces the contract to check if the sender can, in fact, send the token and if the recipient is allowed to receive it.
The specific logic covering who can send and receive can be configured outside the token contract itself.
With this base configuration, you can see why we are excited about ERC-1404. It can be seen as a set of building blocks that can be used to construct financial products.
With this in mind, let’s look at some of the building blocks that ERC-1404 offers to address the compliance requirements above, namely Whitelists and Administrator roles.
We talked briefly in a past article about how to set this up, albeit with a more technical lens. The main idea is that you can set rules around which groups of users can trade with one another. Each group gets its own whitelist; these would then be configured as needed.
In the case of simple flow-back prevention, an issuer would create two whitelists — one for US investors and one for non-US investors and configure them to prevent trading between the groups.
By this point I’m sure you are wondering: “Who actually manages all of this? You don’t actually expect the issuer to handle all of this do you?“
Yes and no. We are specifically talking about issuers of digital securities via private placements. The responsibility does fall on the issuer to ensure all the compliance checks are met. However, this is not a burden they need to shoulder themselves, they can engage partners to support them in these endeavors.
This is where the concept of a “token administrator” for digital securities comes into play.
When we build out bespoke restricted token contracts, there are two types of roles baked in by default: owner and administrator. The owners are the issuers themselves, depending on the token requirements, owners would have the ability to mint more tokens, revoke tokens from a wallet, manage whitelist rules, etc.
Administrators, on the other hand, can only do a subset of these functions. We built ERC-1404 restricted token contract to allow administrators — at the very least — to be able to manage whitelists (i.e. add & remove people from whitelists).
Unlike the token owner role, the administrator function is one that’s built to be shared. The role can be granted to other exchanges, transfer agents, broker-dealers, compliance professionals, and many more.
Beyond the primary issuance
Let’s fast forward a few years and try to imagine a world where many financial products have been issued into the digital security ecosystem. What would the properties of this future look like now that they have been introduced into an interconnected financial ecosystem?
Liquidity wouldn’t be locked into pools blocked by gatekeepers; instead, they would share a large global pool of liquidity and there would be many on/off-ramps.
Given that these financial products have restrictions, on-ramps would require built-in mechanisms to enable access to digital securities as part of their investor onboarding process.
To tie it back to the building blocks we talked about, these are on-ramps that act as administrators that will share the responsibility for enforcing restrictions, including managing the whitelists. These on-ramps could be exchanges, transfer agents or brokerages.
Powering the future
A driving force behind this will be permissionless innovation. All the tools that we are talking about here are in the open source domain. This means that businesses working in this new financial world will not have to build everything from scratch. They would build on top of battle-tested infrastructure.
This space may seem nascent, but the rate at which tooling gets built out is accelerating. We are currently benefiting from the compounding effects of the work that was done in the last five years. In some ways, this is still just the beginning.
Similar to many others in the industry, we are continuing to build products that solve critical gaps in today’s landscape. We’re going to be sharing more of this work over the next few months, specifically how our clients are deploying restricted tokens and the role various 3rd parties will play in the ongoing administration of digital securities.
At TokenSoft, we are working on topics and technologies discussed in this article to support multiple clients go to market with their digital security. We do so with our problem-solver hats on as we seek to map the right technology to any project. If you think we can help, reach out to us on tokensoft.io.