Don't trade the go-live date for more functionality.

Different customers have different requirements and expectations from Fraud Management Systems. However, one thing I have often observed is people missing the forest for the trees. Teams often get dragged into discussing very specific, even niche, details or functionalities when trying to deploy a fraud solution within the organization. This seems even more common among organizations deploying their first fraud solution.

But let me tell you - If you don't have a fraud solution, or if you do, but it's not covering channels, products, or fraud typologies where the actual fraud happens, don't overthink and delay the deployment.

One of our customers' mistakes is sacrificing the go-live date for more functionality. And here I want to say wholeheartedly - please don't. It only makes sense in scarce situations. I'm not saying you should be open to compromise on any functionality - not at all. I suggest the delivery team (customer & vendor) establish a shared understanding of the MVP (Minimum Viable Product) to ensure the critical functionalities are captured in the design blueprint. Everything else is up for discussion.

There isn't a simple formula or set of guidelines for what's hard to deliver and what's straightforward, since each solution is different. Each solution is better in certain aspects and worse in others. For some solutions, integrating with an external system via a REST API might be effortless; for others, rule building and scoring may be fully configurable and the easy part. For others, altering the user interfaces and screen layouts might be trivial.

The general guiding principle should be to understand these specifics and try to deliver the "easy to do" or "out-of-the-box" functionalities that are aligned with the business owner's expectations or desires, and try to postpone those that could delay the process due to complexities of any kind (on vendors' or the customers' side alike).

Regarding this particular topic, I vividly remember one project where the go-live date was the single constant that couldn't be touched; everything else could - from IT architecture, integration, and business functionalities. The CEO decided this himself. I consider this project, to this day, the most efficient one we have ever delivered - it was completed in significantly less time than average, and it was claimed as a huge success by the customer's senior management too.

The benefits of getting the solution up and running in production as early as possible were 1) reduced losses from the go-live date onwards and 2) reduction/mitigation of wasted efforts. Wasted effort in this context is any effort that would ultimately result in no additional functionality or business benefits - most commonly materialized as meetings, analysis, documents, and presentations.

So where did the wasted effort come from, and why did I observe go-live delays?

1. Critical functionality mistake

The first - and probably most frequent - is discussions on specific topics that weren't even that important from a business perspective, and certainly not needed for the project's initial phase. But these had to happen, and we had to go through the tedious (sometimes technical, sometimes business, and sometimes both) discussions on the topic as the customer viewed the functionality as critical.

To mitigate the risk of wasted effort, try to align on what functionality is critical and has to come as part of initial delivery and which functionalities can come later, but be honest about it. Otherwise, you will end up with the same list you started with.

2. Vendor as a partner and advisor

Another situation that leads to wasted effort relates to the established cooperation model between the vendor and customer. Sometimes, customers consider the vendor purely as an IT vendor who only brings technology to the table. Some vendors might even position themselves that way. And that is OK if both parties are transparent about it and consciously manage overall project delivery with that in mind.

I would advise, though, to prefer a vendor who brings to the table not only the technology (the SW) and a team capable of deploying it but also business domain people who will help to shape the final delivery considering the customer's views (business as well as IT) along with the view of the vendor. In addition, if the vendor is experienced, they can provide invaluable input from previous implementations and help mitigate wasted efforts.

One example was when the customer raised the topic of loading historical data into the fraud detection system before going live. This would allow the behavioral profiles to "mature" and make the solution more accurate from day one. This is a legitimate request and makes perfect sense. However, because we've worked with this customer before, we advised against this step in the very first session. We provided several practical reasons (considering their historical data availability and quality, and the effort required to consolidate it from multiple systems). After several weeks of discussions with various business and IT teams, the bank ultimately agreed and decided not to load the historical data. But the damage has been done. Although the discussions happened early in the project, the impact on go-live was still measured in weeks.

3. Business and IT alignment

Though details about the fraud management system within the organization should be a well-kept "secret" and known only to those who need to know, it is imperative to align business and IT stakeholders closely to ensure that "what business wants, IT can deliver - fast."

What do I mean by that?

One of the initial discussions we have with the customer is to identify the business pain points within the fraud domain - what fraud typologies, which channels, and/or which products are the biggest problem and should be addressed on priority. After this discussion, we ask to involve the IT teams and check with them the feasibility of integrating the selected channels and their respective data source into the fraud management system. There could be many reasons why this follow-up discussion is essential. To deliver the project with the highest possible value to the customer, we must prioritize the phases or deployments with the shortest possible time to market (TTM).

It wouldn't make much sense to integrate Internet Banking and Mobile Banking transactions if they were going to replace the systems within the next 6-12 months or if they were planning an upgrade that would impact the integration interfaces. Another example might be an attempt to integrate transactions that were not readily available (e.g., non-financial transactions like login) in middleware. This would require making that extra integration step available to the fraud solution. A specific channel, system, or product may be a high priority from a business perspective but the least preferred option from an IT perspective because of technical complexity or related effort.

To achieve the best possible outcome in the shortest time, align Business and IT views and choose a roadmap that considers both. Otherwise, you might get to start the project with a top-priority use case from a business perspective. Still, it will take more time on the IT side to implement, during which you could have already reaped some benefits of having the fraud system in place - though maybe with a different channel or product.

Wouldn't these compromises impact the outcome?

The answer is easy - YES, they would. Compromise doesn't always end up as a win-win from every angle, but it doesn't mean it will result in a flawed or failed system. We need to go back to the initial paragraph and reiterate the problem - for the trees, we often don't see the forest.

Though we might compromise on some capabilities or functionality, we often gain the aforementioned "forest." Deploying the fraud management system to production is not like switching the light, going from no fraud system to 100% detection capability in a matter of hours. Especially for organizations that didn't have a fraud management system before, this step introduces many new things. There is always a ramp-up phase (usually a couple of weeks) during which the staff is:

1. getting familiar with the system's User Interfaces
2. getting acquainted with the steps and processes configured within the solution
3. getting familiar with alerts and how they are represented in the system
4. learning to operate the different roles of the system
5. knowing what to look for in the alerts - what is "normal" and what is not
6. learning how to use the critical functionality
7. etc.

During this period, the analysts, managers, and call center agents are all getting used to many aspects of their daily work impacted by the new solution. It takes time for the dust to settle and for business to return to normal.

This ramp-up phase will happen, and the sooner you reach this phase, the sooner your fraud operations can reap the benefits of the new system. And how do you know you are back to business as usual? Users will start identifying things that annoy them or that weren't considered in the initial phase, or they'll want them added to make their lives easier.

When does it make sense to postpone go-live in favor of more functionality?

I would say that if you have reached the situation described in the paragraph above - business as usual after phase 1 go-live. This is when it would probably be OK to extend the timelines to get the desired functionality. The moment when you already have a fraud management system in place and are looking for incremental gains on top of the current solution.