AlloyDB AI Fraud Detection: Vector Search Meets

Every financial institution is fighting the same uncomfortable war: catch fraud without making legitimate customers feel like suspects. Block too aggressively, and you're flagging someone's vacation purchase at 11pm as a crisis. Block too loosely, and someone else's retirement account quietly drains. It's not a technical problem with a clean technical solution—it's a values problem dressed up in math.

Which is exactly why a demo Google Cloud published this week is worth paying attention to. Not because it solves the problem, but because of where it's trying to push the solution.

In a four-minute walkthrough, Paul Ramsey, an AlloyDB product manager at Google, demonstrates how the company's managed PostgreSQL-compatible database—AlloyDB—can be turned into what he calls "a high-speed inference engine" for real-time fraud detection. The architecture he lays out is genuinely interesting, and the engineering tradeoffs he names honestly are more refreshing than the typical vendor demo.

What They Built (And How)

The setup uses a fictional firm called Symbol Investments, a stand-in for any large financial institution sitting on years of transaction history. The demo starts with over 2 million financial transactions. Each gets converted into a "feature string"—basically a text representation of the transaction's attributes—and then run through AlloyDB's ai.initialize_embeddings function to generate vector embeddings. These embeddings are numerical representations that capture the semantic and statistical patterns of each transaction, positioning similar transactions close together in high-dimensional space.

The detection engine then works by measuring vector distance: how close is this incoming transaction to known fraudulent ones? If it falls within a certain threshold, the system flags it.

To power the vector index, Google is using ScaNN (Scalable Nearest Neighbors), their own algorithm built on, as Ramsey puts it, "14 years of Google research." The pitch: ScaNN uses up to 4x less memory than HNSW (Hierarchical Navigable Small World)—the other major vector indexing approach—and is engineered to scale to 10 billion-plus vectors. For a system processing high-frequency financial transactions, memory efficiency isn't a minor detail. It's the difference between a system that stays fast under load and one that quietly degrades.

The Part That's Actually Honest

Here's where the demo earns some genuine credit: Ramsey doesn't pretend the threshold problem has a clean answer.

He walks through the tradeoffs explicitly. At a vector distance threshold of 0.021, the system catches 79% of fraud—decent, but one in five fraudulent transactions slips through. Tighten the threshold to 0.011 to catch 93% of fraud, and you're now falsely flagging nearly 20% of legitimate transactions. Loosen it to 0.031 and a quarter of fraud walks right past you.

"Do we inconvenience customers with false positives, or do we let fraud slip through the cracks as false negatives?" Ramsey asks, framing it cleanly. It's a real question, and the fact that he names it rather than waving it away is notable for a product demo. Most vendor pitches skip straight to the impressive number.

The honest answer, of course, is that the right threshold depends entirely on your customer base, your fraud exposure, your regulatory environment, and a dozen other factors that a database vendor can't decide for you.

Enter the LLM

The more novel part of the architecture is what happens in the gray zone—transactions that land just below the fraud threshold, close enough to be suspicious but not close enough to trigger an automatic block.

Google's answer is ai.if(), a function that lets you call Gemini's natural language reasoning directly inside the database query. The demo shows a transaction that the vector model misses at the current threshold—a false negative. When the ai.if() function is invoked, it runs a prompt against the transaction context: "Based on this user's typical spending patterns, does this look like a card testing attempt?" The LLM says yes, and the transaction gets flagged.

"With this hybrid approach, we boost recall and reduce false negatives by over 5% apiece," Ramsey says.

That's a meaningful improvement—5 percentage points in fraud recall at financial scale represents real money. But it also surfaces an interesting question the demo doesn't fully address: what's the LLM actually reasoning over? "Typical spending patterns" suggests the model has access to a user's transaction history as context. The quality of that reasoning depends entirely on how much history is available, how it's structured, and whether the model's prompt engineering is robust to edge cases—users who travel frequently, whose spending is genuinely irregular, or whose patterns changed recently. LLMs are good at pattern recognition across language; they're less reliable when the input data is sparse or unusual.

None of that is a dealbreaker. It's just the stuff you'd want to stress-test before putting it in production.

The Performance Claims

The numbers Ramsey cites for performance are the kind that make engineers lean forward and squint.

Array-based processing of incoming transactions delivers, per Google's benchmarks, a 2,000x performance improvement over row-at-a-time processing—up to 7,700 rows per second. With the optimized ai.if() function using "native in-database execution and surrogate models," that climbs to 100,000 rows per second. He frames this as a 23,000x improvement over traditional approaches, with cost reductions of up to 6,000x, bringing inference cost to "just 1/10 of a cent."

The word "benchmarks" is doing a lot of work in those sentences. Benchmarks are real; they're also controlled. The 23,000x figure almost certainly compares against the least optimized possible alternative—sequential, single-row LLM API calls with network round-trips, no batching, no caching. That's a legitimate comparison if that's what you're replacing, but it's not the comparison you'd make against a well-engineered competitor. The "surrogate models" reference is also worth flagging: these are smaller, faster approximations of the full Gemini model, which means you're trading some reasoning quality for speed. How much quality? The demo doesn't say.

To be fair to Google, they do call these "preliminary results"—a phrase that tends to get buried in the excitement but matters a lot.

The Broader Architecture Question

The deeper thing Ramsey is demonstrating isn't really about fraud detection specifically. It's about a design philosophy: bring AI inference into the database layer rather than exporting data to external services, running models, and importing results back.

This matters because latency kills. A fraud detection system that takes five seconds to reach a verdict is useless for real-time transaction authorization. By running vector similarity, threshold logic, and conditional LLM calls inside the database—using PostgreSQL-compatible SQL—the architecture keeps data movement minimal and decision latency low.

It also means the fraud logic lives alongside the data in a system that engineers already understand. You're not stitching together a database, a vector store, a model serving layer, and an orchestration framework. You're writing SQL with some new functions in it.

Whether that consolidation is a benefit or a risk depends on your organization. Tighter coupling means fewer moving parts and less integration overhead. It also means deeper lock-in to a single vendor's stack—in this case, Google Cloud—and less flexibility to swap components as the AI landscape shifts, which it does, frequently.

What This Is and Isn't

It would be unfair to treat a four-minute product demo as a peer-reviewed system design. Ramsey isn't claiming Symbol Investments is a real firm or that these benchmarks reflect every deployment scenario. The demo is a proof of concept, and a reasonably sophisticated one—it engages with real engineering tradeoffs rather than just promising magic.

What it doesn't address: how the system handles model drift over time (fraud patterns evolve, and the embeddings trained on last year's fraud may miss this year's schemes), what the governance model looks like for a system making automated block decisions, or how you audit an LLM-assisted fraud flag when a customer disputes it.

Those aren't questions Google Cloud is obligated to answer in a demo. But they're the questions any financial institution would need to answer before shipping something like this to production.

The underlying architecture—vector similarity as a first-pass filter, LLM reasoning as a tie-breaker for ambiguous cases—is a genuinely sensible pattern. The hard work of calibrating it to a specific institution's risk tolerance, customer demographics, and regulatory obligations is, as always, left to the humans.

Marcus Chen-Ramirez is a senior technology correspondent at Buzzrag covering AI, software development, and the intersection of technology and society.