I built a Graph database to catch money launderers. Here's what I actually learned.
I want to say upfront: I have not caught any money launderers. I built a database. Whether it would actually catch money launderers in production is a question I can't answer yet, because I have ze...

Source: DEV Community
I want to say upfront: I have not caught any money launderers. I built a database. Whether it would actually catch money launderers in production is a question I can't answer yet, because I have zero production users. That caveat matters and I'll come back to it. Here's what happened. The problem I kept reading about Every AML compliance team I could find publicly describing their stack was running some version of the same setup: a graph database for relationship traversal, a vector database or fuzzy matching library for name similarity, and a service layer stitching them together. Quantexa runs Spark plus Elasticsearch plus postgreSQL plus a graph layer. ComplyAdvantage built a transformer-based name embedding model and runs it against FAISS for sanctions screening, while keeping a separate proprietary graph database for entity relationships. Neo4j has published architecture diagram explicitly recommending you pair of their graph database with Pinecone for the vector part. These are n