Three Priorities To Scale Your Digital KYC Workflows
Know Your Customer (KYC) is an important compliance and regulatory requirement for all Financial Institutions. Anti-Money Laundering (AML) rules are enforced tightly by most regulators and failure could result in big, headline-grabbing fines or the revocation of one’s operating licences. FinTechs must ensure that they aren’t doing remittances, buying stocks or splitting a Dyson Vacuum Cleaner into 3 payments for criminals and terrorists! KYC is a balancing act to get as much mandatory information out of a customer as possible, without annoying them too much. For FinTechs, the aim is to create the most seamless customer onboarding journey and the least frustrating customer verification process for their compliance teams, all while ensuring that things won’t break if the number of new registrations doubles overnight!
Opening bank accounts, for example, are relatively quick nowadays thanks to technology. KYC Analysts rejoice when robotic process automation takes over the mundane, time-consuming tasks, users can sign up for Financial Services from anywhere through an easy-to-use online application and digital verification tools are also a reliable substitute for in-person verifications from an employee. Successful FinTechs not only leverage these new tools but also design their customer onboarding and KYC-checking staff journeys with scale in mind. As long as the compliance teams are always on top of each onboarding case, there’s an (semi) automated verification process running in the background and risk scores get updated in real-time, all is well!
Priority #1: Make Your Platform A “Two-Way Mirror”
Imagine sitting in an interrogation room, staring at your own reflection. On the other side of that glass panel, the police are observing you while a detective comes in. Just like how you and the police both share this set of rooms, the users and admin staff should also share the same product platform! There should be different levels of access and visibility for users and admin staff, so that the client only interacts with the front-end but the admin can “see” both the front-end and execute operations on the back-end.
On the client-facing front-end, designers should focus on data validation, assisted inputs and a sleek UI. Data validation helps guide users on what and how information should be typed into each answer box. For example, date of birth fields could disallow users to type numbers in themselves, but instead invoke a calendar pop-up for users to select a date. Onboarding journeys could also become more convenient when there are drop-down menus with pre-populated fields, a multiple-choice list etc.. Another example would be populating addresses — in the UK, you could type in your postcode and choose your address, instead of typing it all out! Onboarding is the most painful step in the customer journey and is usually a ‘graveyard’ for new leads, as many would prematurely drop out of the onboarding journey if it’s too annoying. FinTech staff/admins could have the option to see which step of the onboarding process a user is stuck on and potentially give them a boost to finish onboarding. However, this would be chaotic and difficult if the front-end platform is very different architecturally and experientially from the back-end, admin-only side.
The back-end should ideally have the same design themes as the front-end to keep things consistent and also have case management capabilities available. Not only should the back-end act as a Customer Relationship Management (CRM) system for staff to view key user information, activity and stats, but also an environment for FinTech staff to collaborate and track tasks. Staff should be able to write notes, tag others and mark tasks as complete on a user’s profile, transaction, support ticket etc. Convenience is an obvious benefit, but the bigger advantage is that having everything in one platform/database creates an audit trail and is much better than working on hundreds of scattered Excel sheets — the regulator will see this as a green flag!
Priority #2: Integrate With Reliable, Independent External Sources
A KYC process wouldn’t be complete without verifying user data and screening users against a third-party data source (this is actually a regulatory requirement in most jurisdictions). At the minimum, all users’ names and names of their ultimate beneficial owners must be run against a widely-used sanctions list (like OFAC, UN, EU etc.) and their countries of residence/operations must not be from a place like North Korea. There are plenty of RegTech providers that allow FinTechs to “VLOOKUP” their userbase against sanction lists, FinCrime warning lists and adverse media warnings through an API.
On top of making life easier for their KYC Analysts, it’s also possible and recommended for FinTechs to use these external data sources to help users complete the registration process quicker (mentioned in Priority #1). The UK Companies House API is an example of a data feed that can pull company and beneficial owner information from the UK Companies Register to simultaneously help the users complete the registration pages and upload their company’s incorporation documents. Open Banking information requests could also be used on the onboarding stage. If I have a bank account with Barclays and have already sat through their tedious onboarding process, I could consent to share my Barclays banking information with the FinTech that I’m registering on via Open Banking, saving both myself and the FinTech some trouble.
It sounds great, but integrating with APIs isn’t really a walk in the park. FinTech engineering teams should be aware of performance limitations, error handling and data characteristics too. It’s all fun and games with the API until one forgets about hitting the 100 API calls per minute threshold and red error messages start popping up in front of the user and the KYC Analysts. It’s always a good practice to monitor the frequency and usage of external APIs, and upgrade the API plan if required. Engineers and Product Designers must also try to figure out every single edge case and ensure that these errors get addressed. It’s very unprofessional to just display messages like “Error#3890D — Code 404” to a grandpa trying to sign up to Coinbase to buy their edgy 13-year-old grandson some Dogecoins. Also, it’s worth also keeping track of the external API provider’s documentation and data standards. Just moving a field by one position on the JSON output could throw the FinTech’s code out of sync!
Priority #3: Run Real-Time Risk Assessment Models
Now that we looked at external integrations, it’s time to also look inward. All Financial Institutions are recommended to use risk-based approaches to conduct customer due diligence (or KYC). Moreover, risk assessments should also be done as frequently as possible, and not just during the customer’s initial onboarding stage. It’s important to continuously keep an eye out for irregular user activity, new adverse media/sanction hits and plain old suspicious behaviour. I think using a quantitative model that gives each user a risk ‘score’ is very subjective and takes a million years to optimise/test. It’s better to just divide your userbase into low (Simplified Due Diligence), medium (Standard Customer Due Diligence) and high (Enhanced Due Diligence) risk. Users could be assigned to each category using a decision tree, and these inputs to those decisions should be easily modified when regulatory climates and business appetites change.
I think of Real-Time Risk Assessment Models like a chain of Excel Formulas that changes whenever another data point changes. For example, a payroll FinTech might have a high risk, digital advertising agency based in the UK sending money on behalf of its Albanian clients (a country on the FATF Grey List before Q4 2023). As soon as the compliance team indicates that Albania is no longer a high risk country on one data table, that simultaneously updates another field that indicates how risky a payment is on the transactions data table, which feeds into another field that indicates the payment beneficiary’s risk on the customers’ data table, which is finally also an input of the customer’s overall risk field. Hope you get the idea! The biggest challenge here would be an engineering one, how do you update these fields quickly when there are a million rows of data, and how would you prevent errors in one field from screwing up your entire database (#REF)?
Putting It Together
Compliance requirements like KYC are often less prioritised in FinTech because it is a cost, it isn’t sexy and it involves regulations. However, thinking about KYC compliance from a Product, Data and Engineering perspective can make this challenge slightly more interesting. Designing a scalable onboarding and KYC process requires FinTechs to put operational tools first and create convenient experiences for both users and compliance staff so that everyone can quickly get through this painful process together!
