Mastering Fraud Solution Implementation - The Art of Defining 'What' and 'How'.

Implementing a fraud solution project requires collaboration from various roles on both the vendor and customer sides. However, a fundamental ownership bifurcation is crucial for the project's success: the customer owns the "WHAT," and the vendor is the primary owner of "HOW".

In my almost two decades of implementation experience and overseeing fraud-solution deployments, I have seen many situations and moments that could have been improved. Many of these suboptimal paths or project side-tracks often result from breaking the premise above (to be clear, projects can stray for many other reasons, and I cover those in other articles).

You might argue that a successful project results from joint participation, ideally genuine partnership, and I would 100% agree. Yet the above premise holds firm in any situation. So, let's break it down.

The customer owns the "WHAT"

Owning WHAT means the customer always defines the requirements. This is a fundamental requirement because once the vendor gets to define the scope for the customer - for any reason,

1. e.g., customer not being mature enough,
2. customer treating the vendor as an advisor,
3. customer's staff turnover,
4. customer engaging 3rd party consultancy to define the WHAT
5. etc.

will ultimately result in the lack of requirements ownership, the customer not agreeing to the delivered objectives (partially or completely), or - what is even worse - agreeing formally but holding a negative perception of the vendor. This is a common way scope creep happens.

This doesn't mean the customer can't leverage the vendor's expertise or use third-party consultants to help frame the WHAT, but the customer must consciously agree to the presented scope, fully understand each item defined in the requirements, and stand behind them. Also not very common, but not unheard of, is that the customer's employee who will ultimately sign off on delivery completion must own, or at least sign off on, the gathered requirements.

Requirements gathering is a critical part of any vendor's delivery process. While vendors might genuinely try to help customers frame the requirements and link them to their solution, misunderstandings can occur if the customer's team does not fully understand these adjustments. Be cautious and, if needed, reiterate that the customer defines and formulates the scope and requirements. At the same time, the vendor might suggest adjustments, amendments, or alternatives.

Sometimes, customers struggle to formulate precise, quantifiable requirements; other times, they list every functionality they have come across in various vendors' proposals and marketing materials. This topic would require a separate article, but here, I will just say that conducting or leveraging the last fraud maturity assessment is advisable. Focusing on the aspects and areas that are supposed to be covered by the intended solution. For example, if the customer plans to cover only internal fraud typology. In that case, he will review the maturity assessment and the existing gaps, metrics, and KPI values of the as-is state linked to internal fraud. This would allow you to formulate requirements and improve the rating in the selected areas. Be specific, and directly link each requirement to the metric it is intended to improve when delivered.

If you don't have a full-scale maturity assessment to go back to, try to conduct at least a short, focused assessment for the areas you are trying to cover with the new solution (though ask yourself if you are sure that deploying this solution to this particular area is really the highest priority item since you don't have a comprehensive fraud maturity assessment to link this requirement to).

Why is the maturity assessment a must? A maturity assessment will allow us to systematically evaluate the area, identify gaps, and prioritize them by severity or potential risk. Even if you could formulate the requirements without the assessment, it might be almost difficult, if not impossible, to put them into priorities. Priorities are important because once the requirements are captured, the next stage starts - agreeing on the HOW, and here, the priorities might play a crucial part.

The result of this process is a "Business Requirements Document" (BRD). This document should list all the expected functionalities from the customer's perspective. Nevertheless, not every functionality has to be delivered. Also, this document doesn't explain HOW the functionality will or should surface in the final solution, as that would break the initial premise of this article.

The vendor owns the "HOW"

Assuming the customer has provided all the requirements, the vendor must review them, assess feasibility, and map them to the solution functionality. This process might, and from experience, should not be linear. Some additional discussions between the vendor and the customer are usually required to clarify the requirements so that the vendor can address each one and categorize the requirement as

1. available out of the box,

2. available after customization, or

3. unavailable

The process is not linear because items often need to move from a lower bucket to a higher one (e.g., from bucket 2 to bucket 1, or from bucket 3 to bucket 1 or 2). The customer and vendor are trying to find an acceptable workaround to ensure maximum coverage of gathered requirements. Only when no further amendments are possible is the final design document prepared, which describes in sufficient detail HOW the requirements will be addressed in the final implemented solution. This document constitutes a "Solution Design Document" (SDD).

Ideally, each item in the BRD will have its counterpart in the SDD, with a granular enough explanation of the functionality provided. This is important for both parties, as only a mutually agreed-upon document will enable successful delivery of the project scope. This is also why the vendor is the primary but not the sole owner of the HOW.

Some items from the BRD might not be translated into the SDD due to

1. low priority,
2. deployment complexity,
3. effort required,
4. etc.

Nevertheless, it is good practice to capture these reasons and final decisions so there is a clear record of the project team's agreement on these items in case of future disputes. This is especially relevant because the BRD and SDD are often mutually agreed upon and signed months after the project's conclusion.

In one of our projects, the entire business team responsible for fraud management in the organization, including the project sponsor, changed after three months from the KICK-OFF date. In another, the project was shifted from one division and owner to another. So, even with proper PM practice, unforeseen challenges can arise and need to be resolved, and it's always easier with a well-documented process during the BRD and SDD phases.

The three ways this breaks in practice

Knowing who owns what is half the battle; recognizing when the boundary slips is the other half, and in practice it slips in three ways.

1. The customer dictates the How - specifying screens, tables, or data flows instead of the outcome, and the solution gets bent into a shape that hampers operational efficacy and makes the solution difficult to run.
2. The vendor drifts into the What - quietly building what is easy rather than what is needed, so "delivered as specified" and "does what we needed" become different claims at UAT.
3. The customer abdicates the What altogether ("you're the experts, you tell us"), and the vendor fills the vacuum with the average of its previous projects.

Each of these is audible in the language of a design meeting long before it shows up in the product, which is the cheapest possible place to catch it.

Conclusion: The Path to Successful Fraud Solution Implementation

In conclusion, a clear bifurcation of ownership - customer owning the "WHAT" and vendor owning the "HOW" - is fundamental to the success of any project (especially fraud solutions). This clear division of responsibilities helps avoid scope creep, ensures clear communication, and facilitates a genuine partnership between the customer and the vendor.

Q: OK, but what should we do if we realize the requirements are not well-defined halfway through the project or if the new project owner might require some adjustments?

A: The most straightforward way would be to conduct a mini-assessment to realign the scope and ensure both parties agree on any changes.

With clear visibility into existing gaps (via maturity assessments) and open, iterative discussions throughout the project lifecycle, both parties can work toward a common goal: implementing an effective, comprehensive fraud solution that meets the customer's needs and withstands future challenges.

So a few words of advice:

1. For Customers: Ensure key stakeholders are involved in the requirements definition process.
2. For Vendors: Always clarify and document any requirement adjustments with the customer.

By clearly dividing responsibilities and maintaining open communication, organizations can not only implement effective fraud solutions but also build stronger, more resilient partnerships. Remember, the key to overcoming fraud lies not only in tools and technology but also in strong collaboration and a clear shared vision.