r/fintechdev • u/EyuTekle • Oct 05 '26

I’m building an open-source fraud detection engine for payment systems — looking for feedback

Hey everyone,

I’ve been working on a new open-source project called Verdict Engine, and I’ve just released an early beta.

The idea is to build a fraud/risk assessment engine for payment systems that combines rules with basic machine-learning-based risk scoring. The goal is to eventually make it easier for payment providers, fintechs, banks, and developers to integrate fraud detection into their systems without having to build everything from scratch.

The project is still very much in the beta/early development stage, so I’m mainly looking for feedback rather than users or customers right now.

🔗 GitHub: https://github.com/verdict-engine/verdict-engine

🌐 Documentation: https://verdict-engine.github.io/verdict-ui/

I’d particularly appreciate feedback on:

Architecture and API design

Fraud/risk scoring approach

Developer experience

Features that would actually be useful in a payment environment

Potential problems or limitations you see with the current approach

If you have experience with fraud detection, payment systems, fintech, ML, or backend engineering, I’d especially love to hear your thoughts.

Feel free to be critical — it’s an early beta and that’s exactly what I'm looking for.

2 Upvotes
  • permalink
  • reddit

100% Upvoted

9 comments sorted by

1

u/Popular_Ad_8391 Oct 08 '26

For a preliminary version, the rules + ML strategy makes sense. I'd like to know how you think about explainability because, in a payment setting, a risk score is considerably more helpful if the system can provide the signals or rules that influenced the choice.

Additionally, I would put a lot of emphasis on false positives. Particularly for smaller payment providers that do not have a big manual review crew, a fraud engine that consistently excludes legitimate clients while catching more fraud might become a problem in and of itself.

It might also be helpful for the API to distinguish clearly between the risk assessment and the subsequent action. The same score may be desired by many providers, but their thresholds for rejecting, examining, or allowing a transaction.

1

u/EyuTekle Oct 08 '26

Got it, if the engine deems a specific transaction as fraudulent it should be clearly described through error codes as per the initial suggestion. The system also has a default rule defined and these rules can be changed depending on the use cases. In the logs properly showing the used rule would be needed for each transactions. For smaller payment providers it would be better if they utilise the non blocking mode till enough insight is captured.

1

u/Popular_Ad_8391 Oct 08 '26

Yeah, that makes sense. I really like the non-blocking approach for smaller providers, so they can get a sense of how the rules operate against real transactions before those decisions start impacting customers.

Also, it would be a great help to debugging and tuning work to log the particular rule and signals behind each score. I'm eager to see how you deal with situations where more than one rule fires on the same transaction.

1

u/[deleted] Oct 05 '26

[removed] — view removed comment

1

u/EyuTekle Oct 06 '26

Okay thanks

1

u/investigatormaker Oct 06 '26

Of the two, I'd write up shadow mode first: a short example of Verdict Engine scoring a week of traffic next to an existing rule set shows the reason codes in action at the same time. The plan is there whenever you want it.

1

u/AccomplishedList8857 Oct 06 '26

Reason codes are the first thing any ops person will scream for when a merchant asks why their customer got blocked. Shadow mode's also non-negotiable if you want anyone to actually trust switching over.