4 min read

Avoiding “Vendor Pinch” when migrating to a new AML/Anti-Fraud/Sanctions Automation System

Regardless of the reason for migrating to a new Anti-Money Laundering Automation System, (System) the conversion process will likely be; costly, complex, challenging, and unfortunately protracted. Here are some things to consider as you begin considering a change.

Preparation and Planning

Strategic planning prior to committing to a project for conversion to a new system will provide you with several key opportunities. Some of these opportunities will be lost as soon as you inform your vendors (existing and potential) of your migration plans. Switching systems can be both exciting and daunting. However, it is wise not to inform your legacy vendor until you have committed to move. Otherwise, you are likely to experience what is known as “Vendor Pinch”. Vendor Pinch happens when a financial institution fails to adequately plan for both: exiting their existing vendor contract and negotiating and entering a new vendor contract (more on this later).

Starting from the beginning

It is critical for an institution to clearly define both the project’s objectives and limitations. Document, in detail, all of the reasons and goals for the migration:

  • Cost benefit analysis
  • False positive impact
  • Enhanced coverage of financial crime risks
  • Regulatory examiner influence
  • Compatibility with a new core system
  • Merger or acquisition
  • Increased functionality
  • A new BSA officer who has previous experience with a specific system
  • Improved data management
  • Enhanced reporting
  • Improved case management and workflow

Identify all of the resources required, both internally and externally to make the anticipated change. These include project management, full-time employees ("FTEs"), AML team, Legal, IT time, and hardware. If this is your first conversion project, seriously consider retaining outside assistance familiar with your institution. Equally important, make sure you understand all of the project’s limitations: timing, resources, hardware, exam findings, audit results and contract terms, etc.

Perform a risk assessment that evaluates the resource requirements and project limitations. Next, make sure you have executive and senior management’s firm commitment for the resources and their approval to move forward with the migration.

Confer with the institution’s regulator

Conferring with the institution's regulator is especially critical if the regulator has suggested a system change or if there have been any recent examination determinations requiring attention. It is important to be thoughtful about communication with the regulator. The purpose of the communication is maintaining an open channel of communication with the agency, avoid surprising the regulator with any changes to the institution’s compliance program, and to assess the regulator’s expectations for the project and manage the project to exceed those expectations.

Establishing a formal timeline and milestones for the project:

A successful timeline for this project will be contingent on managing the expectations, legal requirements, and capabilities of five groups/entities:

  1. The bank’s executive team
  2. The bank’s internal and external resources including your AML team
  3. The bank’s examiner
  4. The bank’s current System vendor
  5. The bank’s future System vendor

As stated at the beginning, if you want to avoid “Vendor Pinch”, keep this project confidential, and manage the timelines of the vendor contracts “FIRST”. Assess what the project will need from your existing vendor before signaling any plans or considerations of terminating the relationship. This will allow you to manage your project within the time and terms of the existing contract without getting pinched.

If your financial institution is larger than $500 million in assets it is imperative, you have a minimum of two and a half years left on your current contract. The project will likely require; at least six months on new vendor selection, two months on contract negotiation, and at least one and a half years for implementation. This leaves 90-days to run parallel (and a month for PTSD therapy).

If you are inside of two and a half years, consider requesting an extension of the existing contract. However, make this request in a manner as to not signal your current vendor of a potential system change. Moreover, if you do execute an extension on the contract be sure and add in a “de-conversion clause” with a specific fee schedule if it is not already there. De-conversion is the process of extracting data from your existing system. The five-year record retention requirement in the Bank Secrecy Act will necessitate the need for this information. Otherwise, you may have to execute a limited usage or look-up-only license with your current vendor for the five-year period of time, which can be very costly. Are you seeing the Vendor Pinch yet?

As you think through timelines and milestones for this project, also consider the following:

  • When stressed for time on this project, you will likely receive greater flexibility from your examiner than from the vendors (unless the bank has unresolved BSA exam deficiencies). Vendors love to use time constraints to their advantage.
  • Most banks have an IT/Operations blackout for the month of December
  • Stick to a strict vendor selection timeline and process; shorter is preferred (3-6 months). Protracted vendor reviews, cause protracted vendor response times (remember time is on the side of the vendor).
  • Be cordial and responsive to the vendors - it will usually pay off in the long run, as they are more likely to respond in kind.
  • Obtain vendor pre-commitment to the process and timelines in writing prior to having them participate in product demonstrations (e.g. if we execute an agreement before year-end will you have us implemented and “live” in 15 months?).
  • Create a scoring worksheet with functionality you are hoping to see during vendor demonstrations for all Bank participants to complete. This will allow metrics that can rank demonstrations rather than relying on participant memory and unstructured notes.
  • If you are planning on using an RFI (Request for Information) for VDD (Vendor Due Diligence) exercise caution as it is easy to create questions that are biased. Keep it brief (this can be a huge waste of resources for both you and the vendor). Ask open-ended questions that require the vendor to explain their approach to the specific concepts; i.e. “how does risk assessment work within your system?’ vs. “does your system risk-rate customers at account opening?
  • During demonstrations, discussions and requests for information be very cognizant of the difference between “configuration” and “customization”. Vendors will state that their systems are capable of what you are asking for but if it requires customization that will add cost above and beyond the negotiated price. Configuration of system parameters should be included already.
  • Obtain your selected vendor’s commitment to Project Milestones/Timeline in writing before contract negotiations.
  • If possible, try to make the selection decision and contract negotiation late in the year since it can provide an opportunity for better contract negotiations and places you in a priority queue for the next year.

As you can see, effective advanced planning for migration from one System to another requires you to assemble the key stakeholders, clearly assess why you are making the change, establish timelines and milestones for the project, create a selection process to choose the new System, and assemble the internal and external resources needed to complete the project. As with many projects, building an integrated team of technical and subject matter experts will help ensure success of the project.