How to Launch a Regulated Product - Pt. 2
August 31, 2021
Compliance for Fintechs – Part II: Know What Examiners Expect
In Part I of this series, we went through the main differences between working with a bank and being regulated yourself. Regardless of which route you decide to take, preparing what examiners expect of you beforehand will save you from a lot of future headaches. What you’ll need includes documentation, a risk assessment, good auditability, solid timelines, training, testing, and to establish a regulatory change management process.
Whether you choose to partner with a bank or work with a regulator on your own, both will expect a lot of documentation, including policies and procedures for all of your operations that have regulatory implications. This is especially true for those that impact consumers and suspicious activity controls (SACs). The true audience for these documents is not your internal team—it’s your regulators and bank partners. They should be written so that a regulator can sit down during your audit and answer almost every question they have about how you’re protecting your customers and preventing financial crimes.
One important thing to consider is that regulatory documentation requests were not developed with startups in mind. For a bank that’s been around for a long time, it isn’t a problem to have a procedures manual that’s updated on a quarterly or annual basis. Any normal startup changes how things are done all the time and before you know it, it quickly becomes a nightmare to ensure your documents accurately reflect what you’re doing.
As you prepare to launch a regulated product, here are a few considerations for properly managing your documentation.
Many of your policies need board approval. This means any time you change them, they must be approved by your board and your bank partner. You don’t want to have to do this often, so write your policies as high-level documents laying out your risk profile and how you plan to mitigate those risks.
Your procedure documents are essentially a detailed overview of the compliance program you’ve put in place. Your procedures implement your policies—anything you say you do in your policy documents should have a procedure that more completely explains how you’ll do it. These procedures should still be written to explain things to your regulator—where your policies are at a macro level, these procedures should be at a micro level. Though there’s a lot more detail, it isn’t exactly a manual your team can follow on a daily basis (as they would in a bank). While the procedures don’t need to be board-approved, they do need to clearly convey the design of your program.
To that end, we recommend creating a third tier of documentation that essentially serves as your team’s operational wiki. This is where you keep the current operating or desktop procedures that your team is executing on a daily basis. This is written for your team, not for an external audience, so it can delve into whatever level of detail is best for them.
Think of updates to these documents as a reverse waterfall—desktop procedures are updated whenever something changes, procedures documents capture thematic or significant changes and explain them, and policies are only changed if some aspect of your business model or the regulatory environment changes.
Historically, these documents would be presented to a regulator at a bank in a stack of binders. Since you’re a tech company, you’re probably using software like Google Docs. This gives you an advantage since it allows you to add document links. Links are your friends—your policies should link to the relevant procedures and your procedures documents should link to the relevant desktop procedures. This way, all of your documents are kept up-to-date without version control problems, which quickly becomes a major problem if you’re dealing with stacks of paper.
Links have the added benefit of letting a regulator dive down to any level of detail and answer their own questions without needing to consult you. The more they feel that your documents are anticipating and addressing their concerns, the better they’ll feel about your company. Your goal should be to show them that you take compliance seriously, and once you reach this goal, your life will be a lot easier..
Finally, and most importantly, maintain records of any changes. Keep a version history backed up somewhere (preferably in multiple places) so you can easily show your regulator how your program has evolved.
A risk assessment is a critical component of any compliance program and is generally the first document a regulator heads to when conducting reviews. To conduct a comprehensive risk assessment, a company should look to the “Five Pillars” and “Three Lines of Defense” paradigms in compliance. Refer to our guide to Acing Your Compliance Risk Assessment for more information about each paradigm.
The design of a healthy compliance program is typically broken down into five areas, or pillars, of compliance. These five pillars are internal controls, a compliance officer or compliance staff, training, independent testing, and customer due diligence.
Three Lines of Defense
The “Three Lines of Defense” of compliance encompass (1) having the controls in place to ensure ongoing operational compliance, (2) regularly performing tests to verify that the controls are working correctly, and (3) auditing your program by performing annual assessments of the effectiveness of the first and second lines.
You’ll need to develop a training program for your whole company, even the engineers, that’s tailored to what they need to know in their role. You can generally sort them into three categories: Most training, middle level, and low level. Let’s take a quick look at each of these.
The group that needs the most training includes the compliance team, the risk team, and customer support teams. These groups all need annual training on a number of areas including AML and any consumer protection regulations that apply to your business.
Your board needs to receive sufficient training to understand what’s reported to them. Their training requires more detail than the rest of your team needs, but less detail than that needed by the compliance, risk, and customer support teams.
The rest of your team should receive basic AML training, to include red flags that may indicate a colleague is up to something, whistleblower and complaint programs, and sanctions regulations.
As with everything else you do, be sure to document your training program thoroughly. Keep copies of any presentations you give and maintain attendance records. It’s very easy for a regulator to check to see if everyone has received required annual training, so be sure to have the documents handy to prove your company’s compliance.
Start thinking about your auditability early. The regulator mantra is “trust but verify”, so consider how you can build a document trail to prove you’re doing what you should be doing to someone who’s going to dig through your files many months later. Ask yourself things like “How would I know how a decision was reached if I came back to it next year?” Save whatever documents you needed to make your decisions and write down your thought process.
Putting extra effort into this can pay dividends down the road. The easier it is for a regulator to understand how things work, the easier your life will be. Anything that can automatically generate an audit trail for you (like Hummingbird) adds additional credibility.
Failing to do something in a required timeline is the single most common cause of regulator problems, largely because it’s something that’s so easy to test for.
You’ll likely have a number of regulator time requirements you’ll need to stay on top of, though it depends on your business model. The most common areas are AML, customer disclosures, and customer response time periods from places like Regulations E and Z.
Keep an inventory of any regulatory timelines that you’re subject to and build tracking and reporting capabilities to ensure your team doesn’t come close to tripping a threshold. As a technology company, you have a much better ability to monitor things in real-time compared to a bank with legacy tech. A robust software like ours provides this capability natively.
As discussed above, the current regulatory best practice for designing and testing a program is called the “Three Lines of Defense.” This means that the first line (the parts of the company that are doing operational work) has controls in place to ensure ongoing compliance. The second line (the compliance team) regularly performs tests to verify the controls are working. The third line (audit) performs annual assessments of the effectiveness of the first and second lines.
Regulatory change management
Do yourself a favor and create an inventory of all the regulations that apply to your business, identify the authority that oversees those regulations, and subscribe to updates from those authorities. Depending on your business model, this can be a complicated and daunting process. There are a number of companies that have sprung up to help manage this process, and it’s worth investing in one to ensure you’re always on top of pending changes in rules before they happen. If you prefer to avoid buying software, be aware that this work will likely require a third to a half of a full-time employee’s workload as you grow.
Get expert advice
If you have follow up questions, or would like recommendations specific to your business case, Hummingbird can help. Book a spot on our calendar for a free, 30-minute advisory session with compliance experts. Our team includes former regulators, compliance program operators, and policy makers; and we’ve helped everyone from pre-launch fintechs to large institutions. See why our customers say that working with us is “like a crash course in best practices for building an effective, scalable compliance program.”
Next up: Part III: Build your Compliance Team