Money is moving faster than ever across Southeast Asia. Thanks to platforms like Thailand's PromptPay and other regional payment networks, it's possible to send and receive money in the blink of an eye. But there's a catch. When money moves in milliseconds, so do the criminals.
PromptPay alone now carries more than 76 million transactions a day. The Bank of Thailand's governor told the BOT Symposium 2025 that scammed funds leave the system in around three minutes, while victims typically take 18 hours to realise what has happened.
Bank of Thailand Governor, BOT Symposium 2025
We're no longer fighting individual fraudsters. We're up against sophisticated, tech-savvy crime networks that work together to steal funds. Thai banks are feeling it too, with around 92% of fraud and compliance leaders in a 2026 BioCatch survey rating real-time payments a moderate or very high fraud risk.
For the risk teams, data scientists and developers trying to stop them, this has revealed a huge flaw in our traditional tools. Your databases, built on neat rows and columns, are great for looking at one transaction at a time. But they're practically blind when it comes to seeing the hidden connections between them.
In the split-second it takes to approve a payment, these legacy systems can't keep up, often letting fraud slip right through. To secure the future of finance, we have to start thinking less about data points and more about the relationships between them.
Short on time? These are the key insights from this article:
|
Fighting a network with a network: how graph databases work
So, to fight a criminal network, you use a better network. That's the big idea behind graph databases.
Think of it this way. Old-school relational databases are like spreadsheets. They're great for storing information in neat boxes but terrible at seeing how those boxes connect. A graph database is different. It's built to map out relationships, storing data just like you'd sketch it on a whiteboard.
- Nodes are your key players, such as customers, accounts, devices and IP addresses.
- Edges are the connections between them, such as SENT_MONEY_TO and USES_SAME_DEVICE.
The database physically stores the connections between data points. So instead of running slow, complex searches to find a link (the multi-table joins a relational database depends on), it just follows the path from one node to the next.
This allows risk models to ask much smarter questions in real time, like using centrality measures to spot the "hyper-connections", such as a shared device or a central mule account, that act as hubs for fraudulent activity.
What does a fraud graph look like for a development team?
For developers, the value of a graph depends on how you model the data and where each piece of analysis runs.
Start with the data model
Shared identifiers become nodes. For application fraud, the decisioning entities are typically customers, applications and accounts. Every identifier an application presents (phone, email, address, device, IP address, national ID) is stored once as its own node and linked by an edge such as HAS_PHONE or USES_DEVICE.
Reuse creates the link. Because each identifier exists only once, two applications quoting the same phone number automatically connect through a single Phone node. In other words, the ring starts to draw itself as data arrives.
Query the neighbourhood at the point of decision
A two-hop check replaces a stack of joins. The query below (in Cypher, the query language used by several graph databases) takes a new application, walks out to every identifier it uses and back to any other application sharing them, then counts how many of those are confirmed fraud.
Response time stays predictable. In a relational database, the same check means self-joining an identifier table for each identifier type, and the cost climbs with every extra hop and every new row. A graph query only touches the neighbourhood around the new application, so latency stays largely stable as the wider dataset grows.
Use graph algorithms to score the network
The centrality measures mentioned above are part of a wider toolkit. The ones fraud teams lean on most are:
- Degree centrality counts how many applications share an identifier. A phone number on 40 applications in a week stands out immediately.
- PageRank and betweenness centrality find the accounts and devices sitting at the heart of money flows, which is often where the central mule account shows itself.
- Connected components group everything that links together into clusters, so you can score a ring as a whole instead of one application at a time.
- Community detection (Louvain, for example) finds tightly knit groups inside larger clusters, which helps separate a fraud ring from, say, a busy shared office address.
Split the work between real time and batch
Real time handles the light queries. Most production set-ups run neighbourhood queries like the one above inline, within the decisioning latency budget for an application or payment.
Batch handles the heavy algorithms. Community detection and full-graph centrality are usually run on a schedule, with results written back to the graph as node properties that the real-time query can read in milliseconds.
Graph features feed your models. Outputs such as linked-fraud counts, cluster size and centrality scores become features in your existing fraud models. That keeps decisions explainable for underwriters and regulators, which is the thinking behind Jaywing's Archetype approach to explainable AI.
Case study: how a graph database broke a fraud ring in the Americas
This is already working in live fraud operations. Let's look at a real-world example. A major financial institution in the Americas was getting hit hard by fraud rings.
The challenge
The criminals were using "synthetic identities", a mix of real and fake information, to apply for credit. On their own, each application looked pretty convincing. But they were in fact part of a massive, coordinated attack. The bank's existing tools were looking at each application one by one, completely missing the wider network behind them.
The fix
The bank brought in a real-time graph database. As every new application came in, the system looked at the application itself and also at how its details (ID numbers, addresses, emails) connected to every other application in the system. The graph was built to score these connections, flagging any suspicious links to known fraud typologies or any "hyper-connected" clusters that pointed to a ring.
The outcome
By moving focus from the data points to the relationships, the graph could instantly see the web of connections hiding the synthetic identity ring. Running alongside the bank's existing system, the graph solution caught an extra 23% of fraudulent applications. As a result, the bank could stop chasing individual bad transactions and start proactively dismantling the entire network.
What does this mean for the Thai market?
As Thailand moves further into open banking and virtual banks, the lessons from this case study are critical for local leaders and the teams building their systems. The Ministry of Finance approved three virtual banks in June 2025, each given a year to start operating, which means more digital-only onboarding and more connections for fraudsters to exploit.
- Move beyond simple rules. Fraudsters easily get around static rules (like flagging transactions over a certain amount). The real goal is to spot when they're acting like a network. In fact, 87% of Thai banking leaders in the same BioCatch survey say they struggle to detect money mule accounts, especially when the networks span multiple banks.
- Plan for your partners. Open banking means connecting with lots of third-party apps and services. A graph is the perfect tool for monitoring that web of partner metadata (like SDK versions or API calls) to spot abuse before it starts.
- Build a smarter foundation for AI. If you want to use AI for risk modelling, you need to feed it good data. A clean, connected graph acts as a "knowledge layer" that makes your AI models dramatically more accurate because they're learning from real-world relationships. Getting that foundation right is a data management job as much as a modelling one.
Where should Thai development teams start with graph analytics?
Fraud is already costly for Thai banks. Four in five banking leaders surveyed by BioCatch say their organisation loses more than US$5 million (around THB155 million) a year to fraud, and around 39% rate their own controls at five out of ten or lower. Meanwhile, the arrival of virtual banks will open new routes in for organised fraud.
Start with the data you already hold. Model the identifiers in your application and payment data as nodes, connect them through the records that share them, and run neighbourhood queries alongside your current rules.
Measure the uplift before you scale. Feed the graph features into your existing models and compare performance against your current controls, as the bank in our case study did when it ran its graph alongside the existing system.
Bring credit and fraud together. Fraud rings rarely stop at one product, and undetected fraud ends up distorting credit models too. Our recent pieces on fraud contamination in credit risk models and whether fraud controls are becoming unsustainable explore that overlap, and our Fraudscape 2026 update covers the fraud trends worth watching this year.
And this is where we can help. Our fraud specialists bring hands-on experience in building linkage scoring and graph analytics to uncover fraud rings across multiple countries. If you'd like to see how that would work on your own data, you can request a proof of concept or get in touch with the team.