We built this because the rules engine kept missing the same patterns.
Fraudpulsar started from a specific frustration: velocity rules that fired a day late on card-testing bursts, and a team that spent more time tuning rule thresholds than catching fraud.
The problem we kept running into.
Diego Ramirez spent several years building fraud detection infrastructure at Karbon Pay, a card-issuing fintech operating in the Southeast. The fraud team was technically strong, the alerting stack was sophisticated, and they had a well-tuned rules engine. The same patterns still got through.
Card testers were probing with $0.50 and $1.00 authorizations, spaced just below the velocity thresholds the rules engine had been calibrated on. By the time a burst was large enough to trigger the rule, the compromised card data had moved on. The rules were optimized for compliance audit trails, not for catching behavioral deviations in real time. Every tuning cycle closed one gap and opened another.
The alternative had been discussed internally for years: a per-account behavioral baseline that could flag the deviation before a rule was written. The engineering blockers were real: the model store architecture, continuous baseline updates that could not block the authorization path, and the latency budget of keeping all of this synchronous. Diego left in 2024 to build exactly that layer. Fraudpulsar was founded in Miami the same year.
Priya Nair joined as CTO and co-founder. She had spent three years building anomaly detection systems at a machine learning research group and designed the per-account scoring engine that keeps p50 latency under 8ms. Marcus Webb, former fraud operations lead at a card-network processor, joined as Head of Risk Engineering. His background shapes what the contributing factors output looks like: readable by a risk analyst at 2am, not just by the model author.
Three people, one focus.
Built fraud detection infrastructure at a card-issuing fintech before founding Fraudpulsar. Based in Miami. His direct experience watching velocity rules miss card-testing bursts is the reason the per-account behavioral model exists.
Anomaly detection and time-series behavioral modeling. PhD program left to build something that shipped. Designed the per-account model store architecture and the scoring engine that keeps p50 latency under 8ms in the synchronous authorization path.
Former fraud operations lead at a card-network processor. Has handled more chargeback reason code disputes than he would like to count. Ensures that every contributing factor string in the score response means something to a risk analyst, not just to a model engineer.
Three things we do not compromise on.
We publish p50 and p99, not just the best-case number. The sub-8ms figure is a measured pilot result, not a marketing claim. If it changes in production, we will say so in the changelog before we say it anywhere else.
Blocking a legitimate customer is also failure, and it is the failure most fraud tools undercount. We track false positive rate alongside catch rate in every pilot review. A high catch rate with a 2% false positive rate on high-spend customers is not a good outcome.
Your risk team should be able to explain every blocked transaction to a compliance reviewer or a disputing customer. Every scoring response includes human-readable factor strings. We do not ship black-box scores to teams whose job involves explaining decisions.