Prepare for takeoff: how to successfully implement a new AML solution
“Which AML solution is right for our business?” is a big question. “How do we implement our chosen AML solution successfully?” is an even bigger one.
In this article, Kerttu Eiskop, Customer Onboarding Manager at Salv, shares our process for onboarding banks, fintechs, and payment service providers onto the Salv platform. You’ll learn how to set up a new AML solution smoothly, the parts of the process that require the most attention, and how the Salv team helps new customers reach their implementation goals successfully.
An overview of the AML software implementation process
While all projects and financial institutions are unique, there are typically two types of projects. The customer is either replacing an existing screening and/ or monitoring solution (such as a legacy in-house tool that’s become expensive to maintain and update) or starting from scratch—for example, a fintech company that’s yet to go live or is launching a new product line.
Now we’ll take you through the typical phases of a AML monitoring or screening implementation project:
Kick-off
Here, the customer will meet their Onboarding Manager, who will work with them for the project’s duration. On the kick-off call, we’ll set goals and expectations between all parties: When is the customer hoping to finish the implementation? Who will support this project? What data do they collect and plan to send to Salv?
The Salv team will have answers to some of these questions already, based on pre-sales discussions. But the kick-off call is where it all starts to happen.
“The kick-off call helps the Salv onboarding team get to know the customer and who from their side will be working with us on the project,” explains Kerttu Eiskop, Customer Onboarding Manager at Salv. “We give them a little overview of what’s going to happen. And then it’s onto the actual implementation work.”
While every project varies, The smoothest projects usually have a few key players:
- Product Manager or Project Lead
- A technical rep (developer or IT person)
- Larger financial institutions may also need a data analyst, but this is project-dependent
Data mapping
Next, start mapping data and configurations. This is a key step and often where the most time and effort is spent during a project.
Financial institutions collect thousands of data points. However, not all of them are necessary for AML. By being selective with the data sent to Salv, for example, what’s relevant for building target scenarios or business logic—customers will ensure they only map what they need.
Our platform prefers a consistent format, such as standard database formats like camel case and snake case. Salv also has predefined indexed fields (e.g., first name, last name, country, date of birth) that most customers already collect. Using these specific field names helps the platform easily read and interpret the data since it’s already set up to recognise them.
“We’re able to begin with minimal data. Some customers choose to start with a smaller dataset and gradually provide more, while others may have more detailed requirements from the outset.,” says Kerttu. “our data model aims to stop customers from having to make complex changes on their side, as this can have a knock-on effect that slows the project down.”
For every data point or schema sent to Salv, there’s a schema validator. This allows customers to configure how the data should be uploaded to the Salv platform. For example, is the data a number, a string of text, or a date/ time? This is one of several measures in place to ensure only clean data reaches our platform.
“It’s a balance between having a lot of data and having the required data that will give you optimal results,” adds Kerttu.
Customisation and configuration
Here, we work with the customer to set up their screening fields and automation rules, custom lists, monitoring scenarios, and risk rules.
At this stage, the Salv team will share a rule library containing a set of commonly implemented rules built from years of working with financial institutions to implement screening and monitoring solutions for varying use cases. “This is particularly useful for smaller organisations, who may have a small in-house fincrime team,” says Kerttu. Whereas for larger organisations, who often know what they want to implement, custom rules are popular, giving them the precise control they need.
The customer will then decide on the lists and fields they want to screen. This data could be from independent watchlist providers like Dow Jones or custom lists the customer has created, which are handy for in-house watchlists and greylists.
Customers can configure the platform to screen and monitor against their own custom data sets, tailoring the platform to their exact needs.
To learn more about the Salv platform, book a call with the team today.
Technical setup and testing
Next, the customer maps all API and webhook flows. Once all rules and configurations are set, it’s time to get testing. Customers can test using historical data, such as past transactions, or dummy data built for testing purposes.
This step is important because it lets us test if the rules and configuration have been implemented correctly as the data set will contain a known amount of true positive alerts.
During testing, if the alerts seem too high or low, rules, fuzzy thresholds and name matching can be fine-tuned until the customer is happy. This shows how the platform performs before it starts consuming live customer data.
The Salv team is on hand to assist during this process and make sure the system is working at its best, whichever route is chosen.
Training
The customer team is then taught how to use the Salv platform. We’ll help tailor the user interface to their needs and adjust any operational processes, ensuring the platform is ready for seamless day-to-day use.
Go-live
Some customers opt for a soft live approach, where the old system is run in parallel with the Salv platform in production. The two systems can be compared, and any further changes can be made before switching over completely. This isn’t a required step but is typically used by larger financial institutions that use Salv.
Once everybody is happy with the testing and the configuration has been updated, it’s time to go live.
“When we’re ready to go live, the onboarding manager is on standby so everything goes as planned,” explains Kerttu. “We hold our customer’s hand through it all, making sure that any last-minute tweaks or fixes are done quickly.”
We offer customers a hypercare support period following go-live, where the onboarding team stay closely involved with the customer for two to three weeks. “This helps us ensure everything runs smoothly and everybody is happy before transitioning the customer to ongoing support,” says Kerttu. “Customers won’t be left to their own as soon as they’ve gone live.”
After the first few weeks have passed and everybody is happy, the onboarding project is complete, and the customer is transitioned to regular support.
To learn more about the Salv platform, book a call today.
