BUILD-AML-IN-HOUSE-0-dirigible-crash.jpg

If you’re losing sleep at night, wishing you could do more to stop the bad guys, worried about protecting your company, stressing about helping your customers, I feel your pain. I’ve been there.

I’m Taavi. I’ve been working to fight financial crime for years. And I can help.

Before starting on the path of crime-fighting and compliance, I studied numbers. I started in a bank fresh out of school, then landed in the fraud team at Skype. Built the compliance engines in Wise (formerly TransferWise). And I’ve been helping great companies develop their Know Your Customer (KYC) and Anti-Money Laundering (AML) programmes ever since.

Through the years, I’ve often thought “I wish someone had told me that.”

Full disclosure, I’ve built my own AML technology company to help with this very thing. But, more on that later.

So this is my attempt to help you avoid your own failings and learn from mine. 6 things I wish I’d known before I built my own in-house AML technology.

My origin story

I’m no hero, but it might help you understand where I’m coming from and why I can help.

When I joined Wise, it was tiny. I’d been preventing fraud in Skype and thought Wise would be a fun, new challenge. We had customers, but the load was manageable. Whatever we didn’t know, we learned. But our workload soon became daunting. As most startups do, we decided it was time to build something. Fast.

We put a few brilliant engineers on the problem and constructed something overnight. Immediately it reduced our manual KYC workload. Crisis averted.

In Skype, I’d built anti-fraud technologies to protect honest people. I was used to digging deep into customer analytics, segments, conversion drivers, pain-points, churn reasons, global schemes. With fraud it was simpler to see fast results. Stopping fraudsters meant cutting company losses.

But AML? I quickly learned that was something else.

Soon, I found myself buried in reading. Long through the night, I was pouring through regulations full of legalese after my wife and I put our kids to bed. I was overwhelmed. I was confused. I was exhausted. And I was beginning to understand that money laundering (ML), terrorist financing (TF), and fraud were entirely different beasts. Terrorists had their own teams of data scientists and the latest technology. If I wanted to have any hope of slowing them down, our team needed to focus in on making technology that could be one step ahead.

Yes, AML regulations were full of long, complicated words. Yes, AML transaction monitoring wasn’t in real-time like other areas. Yes, I was losing several hours of sleep a night. But wading through the jargon was worth it, because every caught transaction could be 10 less people trafficked or one small terrorist group that struggled to profit.

The better AML product we built, the more of a fighting chance we had to slow down evil from spreading.

But there are always unknown unknowns. And we ran into them quickly.

Learning 1. AML is worlds apart from Fraud

In Skype, reducing fraud losses also meant increasing company profits. In AML, however, I found the opposite was true — reducing money laundering meant reducing company profits. The only financial incentive to monitor transactions was simply to cut down on the manual Know Your Customer (KYC) and Customer Due Diligence (CDD) review costs.

Not only that, but back when I dealt with Fraud, I could easily see when we’d caught all the bad guys. It was simple — we no longer had chargebacks.

But AML? How in the world could we even tell? The police would routinely contact us for more information on payments that, to us, looked entirely harmless. It was just one tiny payment in likely an entire web of money laundering. From the little information we had, there was almost no way we could have deduced there was a problem.

Measuring how we could make a dent in the AML problem felt overwhelming. And nigh impossible.

Learning 2. AML technology is more than just stopping the bad guys

I wanted to stop the bad guys. Thankfully, Wise also wanted to stop the bad guys.

However, I learned the hard way that building software that’s really good at reducing money laundering doesn’t mean being really good at pleasing auditors. What they were looking for to ensure we were compliant was worlds apart from the practical, smart, machine-learning AML engine we built.

Not only that, but because the company had licenses all over the world, each country — and even states — had their own auditors and procedures. What, at first, I thought was a simple SQL query away quickly became hundreds of man hours of retrieving information for various auditors to ensure we had complied with all local and international regulations. Add in different timezones, asynchronous communication, questions we never anticipated coming, and auditors asking for information in sometimes outdated technology formats — faxes, anyone? — meant our team suddenly had a massive, growing headache on its hands.

Because we built the system for crime-fighting and not for auditor-pleasing, it meant there was a lot of stuff we had to build all over in-house just to give auditors the visibility they needed to make the right decisions. We did it, but it took far longer than I hoped.

Learning 3. Skipping user testing is not a good shortcut

BUILD-AML-IN-HOUSE-1-aml-vs-fraud.jpg

We built our tools like startup guys often do. In a corner. Throwing things together as fast as we could. We focused on algorithms and machine learning, not user interface.

When we presented our shiny new tool to AML agents, we realised we’d forgotten to ask them about their workflow. How many tabs did it take for them to complete their investigation? What other tools did they need that we forgot to make space for? How did we sort the information they needed? Did it even make sense? What did managers need to help their agents with as little friction and intervention as possible?

We ended up having to go back to the drawing board more often than I’d care to admit.

Learning 4. There’s something called QA. And it’s massively important.

I’ve been an analyst nearly all my life. When I heard about “QA” I thought, “The leads need me to find some cases? Meh. No problem. I’ll just run an SQL query. Download the data into a spreadsheet. Send it via email. Done.”

Boy was I wrong.

When we started, we just had absolutely no idea how much visibility leads would need to QA agent work. I didn’t build QA into our tool because, frankly, I didn’t understand what a pain it would become.

As our product grew, our team grew. And so grew the pain of manual queries. It got to the point that we began granting database access to leads, giving them the base SQL queries, and arming them with enough knowledge so they could pull the cases at least once a week.

A hack. That should never have been if I’d only known then what I know now.

Learning 5. When it comes to integrations, you’re never done.

BUILD-AML-IN-HOUSE-5-technical-integrations.jpg

When we first built our compliance tools, Wise was much simpler. And much smaller. There was still one monolithic code base, one product, and only a few currencies. Microservices weren’t all the rage just yet.

But, as it grew, not only did Wise become more complex, but so did the industry. Bitcoin boom, anyone? And our software was unprepared to add more and more integrations. Every fancy third party tool our agents added — which, by the way, were really cool — multiplied the engineering power we needed to not only integrate it, but maintain it all.

Sad to say, because we didn’t build our tool to be “integratable” we soon found ourselves drowning in fixes, patches, and hacks. Maintenance and firefighting became way more the norm rather than improving, iterating, and innovating.

Learning 6. Engineers are scarce. Buy amazing 3rd-party tools instead.

I know, I know. Yes I built my own AML technology company. So of course this has to be coming.

But honestly, I wish Salv had existed years ago when I started trying to fight ML & TF. If I knew then what I know now, we would have been able to reduce our engineering power by 90%. The unknown unknowns we started with became something that came back to haunt us. The software out there at the time just wasn’t impressive. Or it was so expensive just to even pilot the thing that I couldn’t justify the spend.

I wanted to know that what I would buy was built by people who knew what they were doing. And I wanted to know it would work.

I’ve been in your shoes. I’ve tried building it myself.

We’ve learned the hard way, so you don’t have to. Get in touch and learn how our AML Platform can strengthen your AML controls and take you beyond compliance.

×
ISO/IEC 27001 logo
Aicpa logo
GDPR compliant logo
OWASP logo

We build security to our products and organisation from the start. We use security best practices (incl. ISO 27001, CIS etc.) to ensure that our security management system meets the highest standards.

Salv has an ISO/IEC 27001: 2022 certificate, as well as ISAE 3000 compliant SOC 2 Type 2 report.