Why I Built a Highly Targeted Fraud Vector Detection Capability on IBM Z

Why I Built a Highly Targeted Fraud Vector Detection Capability on IBM Z

Over the last several years, I have participated in countless discussions about fraud detection. Some were with banks exploring new fraud initiatives, while others involved technology teams evaluating AI platforms, architectures, and deployment models. Regardless of the audience, the conversations often followed a familiar pattern. The discussion would quickly turn towards fraud platforms, machine learning models, deployment architectures, latency, throughput, and scalability. These are all reasonable topics, but over time I found myself increasingly wondering whether we were focusing on the wrong problem.

Most of the institutions I spoke with did not have a fraud platform problem. Many already operated sophisticated fraud solutions incorporating rules engines, machine learning, case management workflows, alert management systems, feature engineering pipelines, and years of operational tuning. Some had invested millions of dollars building and refining these capabilities over many years. The challenge was not a lack of fraud technology. The challenge was that fraud continued to evolve. New attack patterns emerged, criminal behaviour adapted, customer behaviour changed, and fraud teams found themselves engaged in a constant battle to identify new signals and improve detection effectiveness. Despite significant investment, institutions continued to experience losses from specific fraud vectors that existing controls struggled to address effectively.

Over time, I began to suspect that we were framing the problem incorrectly. Most discussions centred on platforms, models, and architecture decisions, yet the institutions experiencing the greatest challenges were often struggling with very specific forms of fraud. This led me to a different conclusion. The problem was not necessarily the fraud platform itself. More often, the problem was a fraud vector that continued to evade detection despite years of investment and operational tuning.

Fraud Is Not a Use Case

One of the most common statements I hear in AI discussions is that an organization wants to use AI for fraud detection. At first glance, this sounds perfectly reasonable. The problem is that fraud detection is not really a use case. Fraud is a category of problems, each with its own behaviours, signals, attack patterns, and intervention strategies.

A financial institution may simultaneously be dealing with authorized push payment scams, account takeover, synthetic identity fraud, mule account activity, card-not-present fraud, merchant fraud, and numerous other forms of financial crime. Each of these fraud vectors behaves differently. The signals associated with account takeover are very different from those associated with APP scams. The features required to identify synthetic identities may have little in common with those used to detect mule activity. In many cases, the operational response differs as well.

When fraud is treated as a single use case, discussions quickly become broad and abstract. Teams begin debating platforms, models, and technologies before establishing which fraud problem they are actually trying to solve. I found that the most productive conversations started somewhere else. They began by identifying the fraud vectors creating the greatest losses, the vectors growing most rapidly, or the vectors proving most difficult to detect. Once those questions were answered, conversations about data, features, models, and architecture became significantly more focused and far more productive.

Why I Didn’t Build Another Fraud Platform

This realization significantly influenced how I approached the problem. If institutions already possessed mature fraud platforms, what value would there be in building another one? Established fraud platforms already provide broad coverage across multiple channels, products, payment types, and fraud scenarios. These platforms represent years of investment and continue to play a critical role within fraud operations.

Attempting to replicate those capabilities did not seem particularly compelling. More importantly, it did not appear to address the underlying problem. Most institutions were not asking for another fraud platform. They were looking for ways to improve outcomes against specific fraud vectors that continued to generate losses despite existing controls. Rather than attempting to build a broad fraud solution, I decided to focus on a specific fraud vector and explore whether a highly specialized detection capability could create meaningful business value.

Instead of pursuing breadth, I became interested in specialization. If a targeted capability could materially improve outcomes for a single fraud vector, it would create measurable value while avoiding much of the complexity associated with large-scale fraud transformation programmes. The objective was not to compete with established fraud platforms. The objective was to determine whether a highly focused approach could solve a specific fraud problem exceptionally well.

Why IBM Z Was Interesting

Once the problem was framed around a specific fraud vector, the next question became where detection should occur. This is where many discussions become dominated by feeds and speeds. Conversations focus on latency, throughput, network hops, and architectural efficiency. While these considerations are important, I found they rarely resonated with business stakeholders. Banks do not lose money because a fraud score took twenty milliseconds instead of five. They lose money because a fraud vector continues to evade detection.

The more I thought about the problem, the more I realized that proximity to the transaction was valuable not because it reduced latency, but because it provided access to context. Fraud decisions are rarely made using a single transaction in isolation. They depend on customer behaviour, account history, relationship information, payment patterns, channel activity, and operational data. Much of this information already exists within the systems responsible for processing the transaction.

This creates an opportunity to introduce specialized intelligence directly within the transaction flow, allowing fraud decisions to benefit from rich contextual information available at the point where the transaction is being evaluated. Viewed through this lens, IBM Z was not interesting because it was faster. It was interesting because it was closer to the transaction. The opportunity was not to score transactions more quickly. The opportunity was to make better decisions by leveraging richer context where the transaction already existed.

Start Small, Not Big

Another lesson emerged during the design process. Many fraud initiatives begin with ambitions that are too large. Organizations often attempt to address every fraud scenario simultaneously, seeking broad coverage from the outset and measuring success by the number of fraud problems included within the scope of the project.

I found myself moving in the opposite direction. Rather than trying to solve every fraud problem, I focused on solving one fraud problem exceptionally well. If a specialized detection capability could materially improve outcomes for a single fraud vector, that would provide a foundation upon which additional capabilities could be built. This approach reduced complexity, simplified feature engineering, narrowed the problem space, and made success easier to measure. Most importantly, it created a direct connection between the AI capability and a specific business outcome.

The objective was never to boil the ocean. The objective was to identify a high-value fraud vector, understand the signals associated with that vector, engineer the appropriate features, and determine whether additional intelligence could improve detection effectiveness. Once value had been demonstrated, expansion would become a business decision rather than a technology decision.

Why a Sidecar Approach Made Sense

The final design decision was perhaps the most important. I never viewed the solution as a replacement for an existing fraud platform. Existing fraud platforms already provide broad coverage across multiple fraud scenarios and remain an essential part of most fraud strategies. Replacing them would introduce significant risk, cost, and operational complexity while forcing institutions to reconsider investments that often continue to provide substantial value.

A more practical approach was to allow the specialized capability to operate alongside the incumbent platform. Transactions could be evaluated by both systems simultaneously, enabling detection performance to be compared, false positives to be measured, missed fraud events to be analyzed, and business impact to be quantified using real-world transactions. This created a much lower-risk path to adoption because the solution did not need to replace anything. It simply needed to demonstrate that it could improve outcomes for a specific fraud vector.

This approach also aligned with how most organizations prefer to adopt new technology. Rather than committing to a large-scale transformation programme, institutions could evaluate evidence, measure outcomes, and make decisions based on demonstrated results. If the specialized capability proved effective, it could be operationalized. If it did not, the institution retained its existing controls and operations without disruption.

What I Learned

The most important lesson was that the problem was never the fraud platform. Once the fraud vector became the focus, decisions about signals, features, models, deployment, integration, and architecture became significantly easier. The discussion shifted away from technology for its own sake and towards a much more important question: how do we improve outcomes against a specific fraud problem?

That change in perspective influenced every design decision that followed. It led to a highly targeted detection capability rather than a broad fraud platform. It led to specialization rather than generalization. It led to augmentation rather than replacement. Most importantly, it created a direct connection between AI and business impact. The success of the solution would not be measured by technical metrics alone, but by whether it materially improved outcomes against the fraud vector it was designed to address.

Conclusion

The future of fraud detection will not be determined solely by which platform processes the greatest number of transactions or which architecture delivers the lowest latency. It will be determined by how effectively organizations identify, understand, and respond to evolving fraud vectors. Broad fraud platforms will continue to play an essential role because they provide coverage, operational workflows, governance, and years of accumulated expertise. However, as fraud continues to evolve, institutions may increasingly benefit from specialized capabilities focused on specific fraud problems where additional intelligence can create measurable value.

That realization is ultimately why I built a highly targeted fraud vector detection capability on IBM Z. I did not build it because fraud platforms were failing, nor because existing solutions lacked AI. In many cases, these platforms remain highly effective and continue to provide enormous value. What I observed, however, was that institutions often struggled with specific fraud vectors that required a different level of focus and specialization. Sometimes the greatest opportunity is not found in building broader fraud coverage, but in identifying a single fraud vector that matters and solving it exceptionally well.