
I've spent 23 months building fraud software that never sees my customers' data
A risk team spots a fraud pattern on Monday. They explain it to an engineer on Tuesday. It goes live three weeks later, in the next release — by which time the ring has moved on.
That gap is the entire reason I started building Krino in September 2024. It's a real-time fraud and AML decision engine for fintechs: every incoming transaction is scored in milliseconds against rules the risk team wrote themselves, and anything suspicious opens as a case in their queue. 784 commits and about a thousand C# files later, it's a product.
Three decisions shaped it, and each one made it harder to build and easier to sell.
The cost of that is brutal and nobody warns you about it: no usage analytics, no "let me check your logs", no gradual rollout, no shipping on Friday because you can hotfix on Saturday. Onboarding is someone else's DevOps team. In exchange, the hardest objection in the whole sales conversation disappears before it's raised.
Flat pricing: $1,499/month, everything included.
This category prices per transaction or per decision, which means the better your business does, the more you pay to be protected. I charge one flat monthly fee — unlimited transactions, rules, users, no enterprise tier hiding the good features. My revenue doesn't scale with my customer's volume. That's the bet: I'd rather have a number a CFO approves in one meeting than a pricing page that requires a call.
Explainability over accuracy claims.
Incumbents return a score: 87. When a customer disputes a decline or a regulator asks why, 87 is not an answer. Krino returns the rules that fired and what each one contributed: disposable email +40, datacenter IP +30, six cards on this device in 24h +22 → 92 → review. Unglamorous. Auditable. It closes demos on its own.
What I got wrong
I ran two databases for a year. PostgreSQL for transactions, a separate columnar store for analytics — because that's what "serious" fraud platforms do. Keeping them consistent cost me more time than the dashboards were ever worth. I deleted the second one and moved everything back onto Postgres with partial indexes. The product got faster to develop and nothing got slower for the user.
I also let the same decision path get implemented twice — once for real-time traffic, once for scheduled sweeps. Every bug now has to be fixed in two places. I know exactly how it happened and I still haven't paid it off.
And the biggest one: two years is a long time to build B2B with no public signal. There's no Product Hunt launch for a product a bank installs. Every honest data point costs a meeting.
The question I'd love this crowd's take on: if you sell into a regulated industry, how did you get the first customer without a logo to point at? Everything I've read assumes you can start with self-serve, and self-serve is the one thing I structurally can't have.
Web Site: https://krino.uk
Document: https://docs.krino.uk
The strongest part is how the product design directly removes the biggest enterprise objection: customer data never leaves the customer's environment. The flat $1,499 pricing and explainable rule contributions then make the commercial case unusually easy to understand for a regulated buyer.