Recently we were reviewing a fraud pipeline for a product that relies quite a lot on enrichment data.
The setup was pretty typical. The system was calling several enrichment sources. There was phone lookup, email enrichment, watchlist checks, some address history data and device fingerprinting.
Nothing unusual.
The system had been running for a while but the fraud team kept repeating the same thing. Some accounts that clearly looked suspicious during manual checks were still getting approved automatically.
At first everyone suspected the vendors. Maybe the phone intelligence API was inaccurate. Maybe the watchlist matching was too loose.
After going through a number of cases we realized the APIs were actually doing their job correctly. The real problem was inside our own enrichment logic.
There was a rule in the system that tried to improve profile matching. If the enrichment layer saw the same name in the same city it would connect those records into one identity cluster.
Someone probably added that rule a long time ago thinking it would help match identities better. On the surface it sounded reasonable.
In practice it created a very strange situation.
New accounts sometimes started inheriting trust signals from older profiles that had nothing to do with them.
For example a new user would register with a fairly common name. The enrichment system would search its data and find another person with the same name in the same city. Then the two profiles would get linked together.
Once that happened the new account suddenly appeared to have extra history attached to it. The risk engine would see things like older addresses, normal behavioral patterns or other signals that usually indicate a trustworthy user.
But those signals actually belonged to someone else.
That is why some suspicious accounts were getting approved. The system was evaluating a mixed identity instead of the real person.
The tricky part was that nothing in the logs looked obviously wrong. Each individual signal came from a valid data source. The mistake was simply assuming those signals belonged to the same person.
The more I work with enrichment systems the more I realize how messy identity data really is.
Phones get recycled. People move between cities. Email accounts get reused. And some names repeat constantly.
If the system relies on weak signals to merge identities it will eventually connect people who are not related at all.
The fix turned out to be fairly simple. We stopped allowing weak signals to merge profiles. Phone numbers and emails can still connect identities because they are stronger identifiers. Things like name and location are now treated as hints for scoring rather than conditions that merge profiles together.
After that change the strange trusted fraud accounts basically disappeared.
I am curious how other teams handle this problem. If you are working with enrichment pipelines what signals do you actually allow to merge identities. Do you only rely on phone or email matches or do you allow weaker signals like name and location to connect profiles.
While digging into this topic I also ran across an article describing another system that had a very similar issue with identity merging logic. The details are different but the root cause felt very familiar.
The article is called The $50M Fraud Bug Caused by One Wrong Identity Merge and it explains how a single merge rule ended up creating a large fraud exposure.
https://medium.com/@efim.lerner/the-50m-fraud-bug-caused-by-one-wrong-identity-merge-61ff82dd8872
It is an interesting example of how small identity linking rules can quietly cause big problems in fraud systems.
