By Shijing Lu, Engineering Director at OKX.
Compliance is defined as adhering to legal and regulatory requirements related to financial transactions and activities. It is the process of verifying a customer's identity and ensuring that they are not engaging in illegal activities such as money laundering or terrorist financing. Compliance is usually the first step when new users interact with financial products, therefore having a snowball effect on customer acquisition costs and business growth.
Compliance products generally consist of a number of forms or ID verification procedures. If these procedures are cumbersome and difficult to navigate, it can negatively impact the onboarding experience for customers. This can result in a higher number of customers dropping out of the process and a higher customer acquisition cost for the company.
Complex and costly
Compliance is a complex and ever-evolving area that requires significant expertise and resources to navigate. In recent years, regulatory requirements have become increasingly stringent, particularly in heavily regulated industries such as finance, healthcare, and technology. As a result, businesses must invest significant time and money in compliance to ensure that they meet these requirements and avoid costly penalties.
For example, a report by Accenture found [1, 2] that the largest banks in the world spend an average of $1.5 billion annually on compliance, with some spending reaching as much as $4 billion. The report also found that compliance-related costs can account for up to 10% of a bank's total operating expenses.
In terms of staffing, a survey by the consultancy firm PwC found [3] that compliance teams typically make up 3-5% of a bank's total workforce. However, in some cases, this figure can be significantly higher. For example, a report by Bloomberg [4] found that at JPMorgan Chase, the compliance department grew from around 1,000 employees in 2011 to over 13,000 employees in 2019, making up nearly 20% of the bank's total workforce.
In terms of specific roles within compliance teams, there are often large numbers of employees working on Know Your Customer (KYC) related products, given the importance of customer identification in meeting regulatory requirements. For example, a report by the consultancy firm Celent found that the largest banks in the US employ an average of 500-600 full-time employees in their KYC operations [5].
One reason why compliance products are complicated is the sheer number and variety of products available. As illustrated below, compliance products fall into two broad categories: KYC and Anti-Money Laundering (AML). Each category contains several different products, such as:
- Customer Risk Rating (CRR)
- Simple Dual Diligence (SDD)
- Customer Dual Diligence (CDD)
- Enhanced Dual Diligence (EDD)
- Politically Exposed Persons (PEP)
- Transaction Monitoring
- Sanctions
- Market Surveillance
- Travel Rule
Each of these products serves a different purpose and requires a unique set of compliance protocols.
Orthogonal to the vast number of compliance products available, each product must be customized to meet the specific regulatory requirements of the jurisdiction in which it will be used. For example, KYC requirements in the United States may differ significantly from those in Europe.
Another dimension of complexity comes from the constant changes in regulatory requirements. Regulations can change frequently, sometimes without much notice, and compliance products must be updated accordingly. For example, the United States recently required form W9 to be filed for all customers by all crypto exchanges in 2023. This means that KYC information for many US users needs to be updated and collecting missing KYC information also falls under compliance. Keeping up with these changes can be time-consuming and require significant expertise.
The third complexity is related to user identity information, which can change frequently. Users may move to a different city or country, and in that case, their residential address or compliance requirements may need to be updated. This can lead to a lot of work for compliance teams, particularly in industries with high user turnover.
Finally, as companies expand and acquire more licenses, compliance teams are often asked to provide support for many other regulatory requirements. This can make the compliance process much more complex as different regulations often require different sets of data and compliance protocols.
Conventional solutions and limitations
Compliance product development, like many other products, is conventionally a long-standing process. It involves a complex and often cumbersome process that requires collaboration between several teams, including designers, frontend engineers, mobile engineers, and backend engineers. As shown in the diagram above, the process usually has 4 - 5 phases:
- Designing: Identifying the feature requirements, brainstorming use cases, and designing the user interface.
- Architecting: Designers and engineers work together on engineering feasibility and trade off some features for implementation timelines.
- Implementation: Mobile, web, and backend engineers work together and implement the features on all ends.
- Launch: Intense QA testing, A/B testing, and stage rollouts to make sure the new features are released safely.
This conventional method of developing user-facing features is capable of delivering visually appealing and reliable features. However, it is not without its drawbacks.
One of the primary drawbacks of this method is that it is not flexible enough to handle compliance products whose requirements change often. Every time requirements change, design and implementations must also change. This can be a time-consuming and expensive process that can slow down the development cycle.
Another drawback of the conventional method is that it is not scalable, especially since OKX has multiple product lines (Okcoin App, OKX App, OKX Lite App, and OKLink App). All of these applications have different compliance requirements. With each product or application, similar but slightly different compliance products must be developed and implemented separately, leading to a significant amount of duplication of effort and resources.
Additionally, this method can be challenging to manage, especially for Okcoin, where the development teams are in different time zones (Beijing, Hong Kong, Singapore, California, and New York). Communication gaps among teams happen from time to time and can result in delays in the development cycle, leading to missed deadlines.
Our solutions
In lieu of these challenges, we built a framework for building a flexible and cross-platform UI framework, leveraging the power of componentized UI, protocol-oriented backend, and a customized templated engine. By utilizing these techniques, we reduced the amount of engineering work required to build and maintain the compliance UIs while still maintaining the flexibility to customize the UI as needed.
1. Componentized UI framework
Componentizing UI elements means three things:
- Breaking up UI components into standard and re-useable parts
- Finding out all possible varieties of the component and summarizing a proper UI specification for this component
- Implementing different representations of the UI component on different platforms and different apps
The images below are examples of the card element. First are what the UI element looks like on Okcoin and OKX mobile applications and on the web. Next are the UI specifications.
iOS & Android - Okcoin
UI specifications:
{
"type": "card",
"icon": "account-circle",
"title": "Upload your ID",
"subtitle": "Use a photo ID that shows your name..."
}
The example above illustrates how a UI component on different platforms is defined by backend provided configuration. Of course, this is only the tip of the iceberg. In practice, many non-UI such as page navigation, vendor integrations, and client side validations are also standardized as client-side components. A good example of this is address auto-completion.
The specification defines a text input with an address auto-completion capability. When a user types text into the text input field, it queries the "listUri" endpoint with query parameters read from other UI components whose IDs are "countryOfResidence" and "roadAddress", respectively. The ending request will look similar to:
GET /v3/compliance/address/list?country=US&text=london
The response then consists of a list of objects that can be displayed as a drop-down list as shown below:
UI specifications:
{
"id": "roadAddress",
"type": "input-text",
"label": "Street address",
"placeholder": "Enter street address, apt., suite, etc.",
"required": true,
"autoComplete": {
"listUri": "/v3/compliance/address/list",
"listUriParams": {
"country": "countryOfResidence",
"text": "roadAddress"
}
}
}
Componentized UI framework can be compared to a set of building blocks. Each component is a self-contained unit that can be reused across multiple projects and platforms. This approach significantly reduces the amount of time and resources required to build UI elements, as developers can simply plug-and-play pre-built components instead of building each element from scratch.
2. Protocol-oriented backend
Componentized UI framework defines the protocols of how the backend talks to the frontend. We took it one step further and standardized how the backend should implement protocols. In other words, we defined the protocols of the protocols or protocol abstractions.
As illustrated below, the protocol abstractions have two layers and several interfaces:
- A state machine that defines the navigation rules (internally known as "playbooks").
- Various interfaces or abstract classes that define how data flows.
For example, ContextManaging defines how client submitted data is validated, how some derived context can be resolved, how context can be written/read to/from the database, how context change events can be broadcast and consumed, how context is "rendered" into detail UI view models, etc.
With protocol abstractions, any backend service can implement the abstracted interfaces, build a playbook service, and start to provide configurable UIs tailored to specific business needs. This gives great flexibility to different business teams as illustrated in the diagram below. On the one hand, the client SDKs, which can render the configurable UI, are shared. On the other hand, different services don't have dependencies on each other and are able to store data separately.
3. In-house template engine
During development, we realized that the java template engines are either YAML unfriendly or not expressive enough for our use case, so we ended up building our own template engine. The following is an example of how expressive our template engine is.
- rule: '!!target'
value: '#$target'
- key: investInfo
value:
type: form
title: '@i8n_title'
items:
- '#accountPurpose'
- '#fundSource'
- '#occupation'
- '#depositVolume'
- '#birthCountry'
cta:
type: cta
items:
- type: cta-button
text: '@i8n_submit'
action: submit
target: '#investInfoTarget'
The template shows how if "target" exists in the context, then read the context value first and unpack the template. Let's say the context has:
"target: 'investInfo'"
The template engine will read the "investInfo" template, call the locale service, get the localized title and text, and re-run template evaluation. All references are materialized. The end result is shown in the screenshot above.
Compared to other template engines like FreeMarker or Thymeleaf, our template engine is not only expressive, but also YAML-friendly and capable of handling nested de-referencing and customized localizations.
Configurable compliance solution
Compliance is a crucial part of the crypto industry that comes with a high cost and high complexity. Our solution offers a new way to build compliance products that is flexible and scalable to handle changing regulatory requirements and build similar products on different platforms. Our framework leverages the power of componentized UI, protocol-oriented backend, and a customized templated engine to allow for the quick building of UI with configurations, allowing different services to build configurable UIs independently and expressively.
With our solution, companies can improve their compliance products, streamline the development process, reduce costs, and enhance the onboarding experience for their customers.
References
- Compliance Risk Study - 2022 | Accenture
- Blockchain could save investment banks up to $12 billion a year: Accenture
- Bank regulatory compliance services
- The compliance function at an inflection point
- IT and Operational Spending in AML-KYC: A European Perspective | Celent
NOTHING IN THIS ARTICLE IS A SOLICITATION TO BUY OR SELL DIGITAL ASSETS. OKX DOES NOT ENDORSE ANY PARTICULAR DIGITAL ASSET OR STRATEGY. DIGITAL ASSETS HOLDINGS INVOLVE A HIGH DEGREE OF RISK, CAN FLUCTUATE GREATLY ON ANY GIVEN DAY, AND MAY EVEN BECOME WORTHLESS. YOU SHOULD CAREFULLY CONSIDER WHETHER TRADING OR HOLDING DIGITAL CURRENCIES IS SUITABLE FOR YOU IN LIGHT OF YOUR FINANCIAL CONDITION. OKX DOES NOT PROVIDE LEGAL, TAX, INVESTMENT, OR OTHER ADVICE. PLEASE CONSULT YOUR LEGAL/TAX/INVESTMENT PROFESSIONAL FOR QUESTIONS ABOUT YOUR SPECIFIC CIRCUMSTANCES.
