2. Introduction
• These slides contain some of my learning as a result of project
managing the delivery of a new Financial Crime system and
new processes into a bank.
• These thoughts represent my own lessons learned from the
experience and/or considerations I would make if working on
a similarly scoped project or programme in the future. They
do not necessarily represent actual events.
• I am sharing them with LinkedIn connections in the hope that
someone might benefit from the insight and I’d welcome any
comments that over time might help keep them up to date or
indeed improve them.
David Allsop
December 2016
3. Scope
Functionality:
• Customer Screening
• Transaction Monitoring
• Real-time Payments Screening
Banking Customer Segments:
• Retail & Wealth
• Local Business
• Corporate
Project Scope:
• 3rd Party Case Management & Workflow FC System & Integration
• IT Operations / Service Management
• Business Operations & Risk Policy Processes
4. 3rd PartySuppliedSolution-Considerations
• Obtain approval to the contract and terms in writing from the CIO and
Accountable Exec. If they don’t agree don’t proceed until they do.
• Get IT Operations to identify a future Service Manager for the 3rd party
application from the outset. Obtain requirements that match the organisations
existing and growing expectations of quality and performance.
• Ask the software supplier to provide a Project Manager to join the in-house
project team, i.e. make it clear that their expertise is being used on the inside
– to meet the bank’s goal and objectives - and it’s not just about an at-arm’s-
length delivery and run.
• If buying all 3 modules focus on Customer Screening first. Create a Proof of
Concept (POC) / Prototype initially, in an environment where integration with
versions of the Bank’s key systems can be made. Test rigorously, including how
to break the system – i.e. performance and capability. Grow the POC
throughout the project lifetime.
• Ensure that internal system platform architects are accountable too.
• If replacing a current system document the current model & the gaps you
expect to be filled by the new system.
• If it is installed in another bank visit them after you have documented your HL
Design and you clearly understand in detail your expectations.
5. CustomerScreening-Considerations
• Unambiguous and Clean Customer data is absolutely critical.
• In Requirements and Design, understand what data the software
expects to handle. Map it to current internal data categories. Find and
fix any gaps and ambiguity.
• Resolve issues with Country (of birth or nationality) ISO codes. What
classification does the new system use and how does this also map to
the external Watchlist you are going to use (e.g. Thomson-Reuters v
Dow Jones). Do you want to check “Alias” names too?
• Define detailed segmentation rules. Define an Active v Inactive
Customer. You don’t want to be screening anymore Customers than you
need to. Mapping customers to WLM categories and then mapping
these to data rules used by the system are fundamental.
• The new system will generate Alerts differently to your existing system.
Use the POC to test (functionality and performance) and manage the
parameters/settings to ensure Financial Crime Risk teams are happy.
Create FC Operations FTE projections. “The Life of an Alert” might be a
useful document. What can each user expect to be able to do?
• If you can, implement in parallel with an existing system for a period of
time. This will achieve credibility with Risk & Operations.
6. TransactionMonitoring-Considerations
• Map the Rules & Settings used in the current system. Compare this
to how the new system is configured. Does a difference in logic
materially affect the dynamics of Alerts?
• If building from scratch, consult the FCA Guidelines documentation
in detail. Understand your Customer’s use of different payment
types and grade the levels of risk, (i.e. segment 2 payment type = “x”
level of risk). Financial Crime Risk Policy should own and complete
this task.
• Logically understand how combinations of Rules might create
multiple Alerts and how Operations can and should manage these.
Does it increase FTE? Can it be presented in risk category order?
• Use the POC to test and ensure that Customers are not being missed
because of a build of of Customer bad data that excludes the
Customer from screening.
• Ensure that ownership of the configuration of Rules and Parameter
Checks is clear, signed off by Risk Committee and is documented.
7. RealTimePaymentsScreening-Considerations
• Integration into the End-to-End Payments Flow within the bank is
critical. Payments Architecture needs to sign-off the Design and during
Build and Testing the Payments Platform teams need to be heavily
involved.
• If there are any Customer “Bad Data” issues still outstanding these
must be fixed before Payments Screening goes “Live”.
• Current & Target Operating Models need to be created during Design,
down to the level of Detail agreed with the Business/Operations. This
is also true for Customer and Transaction Monitoring.
• Performance Testing results must meet Critical Success Factors.
• Implementation: The Cut-Over approach from the existing system to
the new one needs a sub-project. Ideally, run a Dress Rehearsal.
Understand how payments under investigation at the point of Cut-
over will be run down and either released or blocked from the
required system. The existing system may need decommissioning
• Temporary staff may be required in Operations initially until proven
process and efficiency is achieved.
8. KeyConsiderations-Summary
• Initiation:
• Procurement / Supplier Management governance & process
• Business Case – Worst & Best. Is Worse case acceptable to Steering?
• Ensure that you will have enough skin in the game from the supplier. Embed their resources in
the internal project team as well as having a forum to engage.
• Design:
• Current Business & Payments (IT) Operating Models need to inform a “minimum requirement’
future design. A Customer data design/mapping is essential.
• Detailed Business Operational Designs are needed for all modules – include changes to Risk
teams and processes. Consider temporary Org structure if operating a Proof of Concept.
• Architecture – someone needs to own the E2E end architecture which means understanding and
approving how the new system integrates.
• Build and Test:
• The Functional Specification that the Supplier will deliver needs to be bomb-tested. If necessary
re-write it in the language normally used by the bank’s own analysts. If not clear enough
investigate and eradicate any ambiguity.
• Functional and Performance testing needs the right amount of time. Implementing one module
at a time (e.g. Customer Screening) and using a POC to test integration as well as functionality is
recommended.
• Test Alert generation against each Data check and setting, even down to testing generating an
alert for each individual High Risk country, city/town and Sanctions / PEP candidates.
• Agree frequency and scope of uploading the WLM from the external source.
• If integrating with Elmer, SARs will need a test slot with the NCA.
9. KeyConsiderations–Summary–(continued)
• Deployment / Business Readiness:
• Use a Dress Rehearsal to model the cut-over from old to new. Include the Business (Operations)
in this activity so that they have confidence. This will be particularly critical for payments
screening.
• Ensure that there are no P1 or P2 issues outstanding from OAT sign-off.
• You can’t afford to make significant compromises on Test Defects relating to data in order to
meet a time deadline.
• New Transaction Monitoring Rules need to be tested first.
• The Detailed BOD, UAT Results and any application specification and/or UI Design should have
been used to create Procedures and enable Operations staff to complete training; getting to
know their way round the system before it goes into Production.
• The BOD should have documented how the end-to-end SAR process will work. Does the system
enable integration with Elmer (NCA) to deliver SARs via encryption or is it still a manual process?
• Financial Crime Risk Policy (or similar) structure must own and manage the configuration of
Alerting Rules and Parameters. The project needs evidence that Steering members are happy
that a governance framework and new processes to manage this are embedded. This may
include some Administrator rights to issue control User access to the new application, if not
managed separately by an Applications team.
