Mastering Fraud Solution Implementation - Data Is All You Need. Getting It Is the Hard Part.

"We want to monitor card transactions" is enough to start a business discussion. There is still quite a lot to work out before anyone can connect the systems.

Which messages will the fraud solution receive? Will they arrive before a payment goes through, so it can be stopped, or afterward, to tell us what happened? We also need to know what information about the customer will arrive with the request. These details become clear during design.

In my experience, integration is often one of the main things that determines when a real-time fraud solution can go live. A requirement that sounds simple in a business meeting can involve several systems and message types. Working through that detail is a normal part of design, and the project plan needs to allow time for it.

Part 9 of Mastering Fraud Solution Implementation. We have selected the solution and agreed on the business requirements. Now we move into detailed integration design: what information the fraud solution needs, where it comes from, and when it must arrive. This builds on the responsibilities discussed in The Art of Defining 'What' and 'How'.

What exactly are you integrating?

Before You Ask for AI, Check Your Pantry asked whether the bank has the data it needs and whether that data is usable. During integration design, we need to work out how the information will reach the fraud solution.

I normally start with a list of the financial and non-financial events commonly used for each channel. Then I work through it with the bank's business owners. They know what they want to detect and where they need a fraud decision. The integration specialists help identify the systems and messages that can supply the information.

The payment itself is only part of the picture. A login, a new beneficiary, or a changed mobile number can help explain a payment that follows. The bank may only need these events to build a picture of the customer's activity. But it may also want to check a new beneficiary before allowing the customer to add it. In that case, the message has to reach the fraud solution while the action can still be stopped.

We also need to know what happened after a payment was assessed. Did it go through, or did it fail? In the implementations I am describing, that result helps the solution keep an accurate record of the customer's activity. An attempted payment and a completed payment tell us different things. A single payment may therefore reach the fraud solution twice: first for a decision, then with its outcome.

This is why I would be cautious about estimating the integration work from a list of channel names. For each event, agree where the information comes from, what it means, and when it must arrive. If something is missing, decide who will provide it and whether it is needed for the first release.

These decisions belong in the integration section of the Solution Design Document (SDD). The business owners and technical teams need to agree on them before the interfaces are built.

A field name is not enough

The bank may not have a fully up-to-date document describing its integrations. These connections change frequently. Its specialists may need to look at the code or integration tools to confirm what the messages contain. They can usually find the information, but pulling it together takes work.

What concerns me is when we guess what a field means from its name or a few sample values. I would want a data dictionary: a description of each field, what it contains, and what its values mean. The fraud business owner needs to understand this too. That information will be used to write rules and interpret alerts.

If a field is unclear, find the person responsible for the source system and resolve the question during design. Then check the messages that actually arrive during testing. Even a carefully prepared mapping document can miss an unexpected value or a misunderstanding about how the source system works.

Enrichment: adding the information the message is missing

Enrichment means adding useful information to a message before it is assessed. Sometimes that comes from an external provider. Often, the bank already has it somewhere else.

Available balance is a good example. Internet or mobile banking may already show it to the customer, yet leave it out of the payment message. Core banking already knows the balance, so there may have been little reason to send it back with the payment. The fraud solution sitting between those systems may still need it.

Where practical, I prefer to include that information in the message earlier, using what the channel already obtains. That can avoid another request to a separate system while the payment is waiting for a fraud decision.

We still need to agree how current the information must be. A customer segment usually changes slowly, so a stored value may be suitable. Available balance can change between transactions. For a rule that depends on the balance, the bank needs to agree when it will be captured and how old that value can be when the rule uses it.

I would ask the same questions about an external data source. What will it help us detect? How will the information reach the fraud solution, and will it arrive in time to be useful?

Response times and fallback

The bank has a time limit for processing the transaction. The middleware team needs to work out how much of that time can be given to the fraud solution, alongside everything else that has to happen.

Around 100 milliseconds is an example from my experience, although requirements vary. In the implementations I describe, that clock starts when the request reaches the fraud solution and stops when it returns a decision. It includes running the rules and models and reading the profiles held inside the solution.

If another system adds information before the request arrives, that takes additional time. It is outside the fraud solution's own response time, but it still counts toward the bank's overall limit. This is why a fast fraud decision alone does not prove that the full transaction can be processed quickly enough.

We also need to agree what happens if the fraud solution does not respond in time. In my experience, the usual arrangement has been for middleware to continue sending the transaction to the backend systems. Existing checks still apply, but the transaction proceeds without that fraud assessment. The bank needs to understand and explicitly agree to this behavior.

Missing enrichment is a different problem. The fraud solution may be working normally, but some rules may depend on information that did not arrive. Agree which rules can still run and how to handle the transaction in that situation. Those decisions should be made before the system encounters the problem.

Keep the data path manageable

As I explained in Don't Buy the Demo, I generally prefer the bank to build the connections from its channels using technology it already operates. That assumes it has an established team able to do the work.

The reason is practical. The integration layer keeps changing, and the bank needs the freedom to make those changes without returning to the vendor for every adjustment. Using its existing technology also makes it easier to inspect what is happening and support audits. It avoids adding another component that someone has to learn and maintain.

Be clear about responsibilities. The bank defines what information and behavior it needs. The team building each component is responsible for how it works. Agree who will build, test, and maintain each connection.

The fraud business owner also needs to hear about relevant changes to the source messages. They can assess whether existing rules will be affected or whether new information would help detection. Not every technical change needs to be passed through to the fraud solution.

Plan how the integration will be tested

During design, agree how you will check that the integration works. System integration testing (SIT) follows messages through the connected systems. It checks whether the right information arrives, whether the systems handle it as agreed, and whether the expected response comes back. Include missing information and timeouts as well as transactions where everything works.

Performance testing also needs to reflect how the bank's transactions arrive. I encountered this when testing a salary-processing use case. Payments went to many different employees, but they all updated the same employer's profile. Those repeated updates competed for access to the same record and could slow processing down. We called this a cardinality issue.

This was found during testing. Salary processing was a specific part of the scope that needed its own design. In my experience, these batch payments often sit outside the initial real-time fraud integration.

The lesson is that transaction volume alone is not enough to describe a performance test. It matters whether the transactions are spread across many profiles or repeatedly update the same one. Test data that spreads the work evenly can miss a bottleneck in the bank's actual flow.

User acceptance testing (UAT) then checks whether the configured solution does what the business asked for. Users see the information in alerts and investigation screens, where they may notice something unexpected. Ideally, questions about the data have been resolved in SIT. In practice, UAT can still uncover something that was missed. Both stages need time in the plan.

Changes after go-live

Channels and messages will keep changing after the solution goes live. Some changes have little relevance to fraud detection. Others may finally provide information the fraud team has wanted for years. The business owner needs to know about relevant changes so they can decide what to bring into the solution.

One thing I strongly discourage is changing what an existing field means. You then have old and new records using the same field for different things, which makes the history difficult to interpret. If the bank needs to introduce a different meaning, I prefer a new field that means the same thing throughout its life.

There will also be gaps you choose to live with. That can be a reasonable decision if you understand what the missing information prevents you from detecting. Record the gap, assign someone to own it, and revisit it when the channel or the business need changes.

What this means for you

Before signing off the design, take one type of fraud you want to detect and work through it with the fraud business owner and integration team. Identify the messages needed to assess the activity and confirm what happened afterward, then agree what each must contain and when it must arrive. Use that example to check the planned tests, including what happens when information is missing or a response is late.

Next in the Mastering Fraud Solution Implementation series: The Long Middle, on keeping decisions, responsibilities, and testing on track as delivery progresses.