FINANCIAL CRIME PROJECTSCONSIDERATIONS FOR A PROGRAMME OR PROJECT MANAGER

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 AllsopDecember 2016

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

3rd Party Supplied Solution - 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.

Customer Screening- 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.

Transaction Monitoring - 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.

Real Time Payments Screening - 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.

Key Considerations - 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.

Key Considerations – 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.