How Curve Uses BigQuery Graph to Catch Fraud Rings at Scale

Traditional fraud detection often flags individual suspicious transactions but misses the organized fraud rings that operate by sharing devices, cards, and contacts across many accounts. Curve, a UK-based financial super-app, faced this multi-hop problem: uncovering these hidden chains of connections using standard SQL required massive self-joins that became computationally impractical at the scale of millions of users and tens of millions of connections. The real tension was between needing to see the network and the crippling cost of doing so in a relational database.

Curve’s solution was to adopt BigQuery Graph and its native Graph Query Language (GQL), which allowed them to keep their data inside their existing BigQuery warehouse rather than migrating to a separate graph database. By modeling their payment ecosystem as a property graph—where users are nodes and shared identifiers (devices, funding cards, contacts) are edges—they replaced dozens of lines of complex JOIN logic with intuitive GQL MATCH patterns. This approach lets them traverse billions of connections with high performance, and crucially, combine graph traversals with standard SQL and ML workflows in a single query, making it accessible to more analysts without requiring deep graph-language expertise.

The operational and financial impact has been significant: Curve estimates graph-based automated blocks saved ~$12M in transaction losses in 2025 alone, with graph-powered queries achieving roughly 72% accuracy in identifying fraudulent users. GQL also enabled faster rule refreshes, moving from slow one-hop queries to deeper traversals, and opened the door to feeding graph features into their ML models at inference time. For builders, the key takeaway is that native graph analytics within your existing data platform can solve the multi-hop problem without the migration tax, turning raw relationship data into a real-time, high-precision fraud detection layer.