A business rules engine is software that stores and executes business logic separately from application code. Rules are written as conditions and actions, kept in a repository the business can edit, and evaluated against the facts of a case at runtime. The point is that policy can change without a code release, and without the people who own the policy filing a ticket to get it changed.
That is the definition, and it has been a good idea for forty years. What has changed is not the rules layer. It is what has to happen before the rules can run at all.
How does a business rules engine work?
Four parts, in most implementations:
- The rules themselves. Conditions and actions. If the applicant's debt service coverage is below 1.2, decline. If the invoice total exceeds the purchase order by more than 2%, hold for review. Written as decision tables, as rule sets, or in a controlled natural language depending on the product.
- The repository. Where rules live, versioned, with who changed what and when. This is the part that turns a pile of if-statements into something auditable.
- The execution engine. Given a set of facts, it works out which rules match and in what order. Many engines use the Rete algorithm, published by Charles Forgy in 1979, which trades memory for speed by keeping a network of partial matches rather than re-evaluating every rule against every fact.
- The authoring surface. How a non-engineer writes and tests a rule. This is where products differ most, and where most of the buying decision actually gets made.
Engines also differ in how they reason. Forward chaining starts from the facts and works out what follows, which suits classification and eligibility. Backward chaining starts from a goal and works back to what would have to be true, which suits diagnosis and troubleshooting. Most commercial engines do forward chaining by default.
Business rules engine, BRMS, decision engine: what's the difference?
These get used interchangeably in vendor copy, and they are not the same thing.
| Term | What it covers |
|---|---|
| Business rules engine | The execution component. Give it facts, it tells you which rules fired and what the outcome is. |
| BRMS | Business rules management system: the whole product around the engine. Authoring, versioned repository, testing, deployment, governance, access control. Every BRMS contains a rules engine; not every rules engine ships as a BRMS. |
| Decision engine | Owns the decision end to end. It gathers the facts, chases what is missing, applies the rules, and returns an outcome with reasons and evidence attached. |
| DMN | Not a product. Decision Model and Notation is an OMG standard for writing decision logic as tables, with a hit policy for how multiple matching rows resolve and an expression language called FEEL. It exists so a decision written by an analyst is executable without translation. |
What rules engines are genuinely good at
A great deal, and it is worth being precise about it, because the category has earned its place.
Rules engines solved a real and expensive problem: business logic buried in application code, changeable only by the people who maintain that code, on their release schedule. Pulling that logic out and giving it a repository, a version history and an owner was the right architectural call. It is why insurers can reprice a product without a deployment, why telcos can change an eligibility rule in an afternoon, and why a pricing exception in a manufacturing ERP is a table row rather than a merge request.
They are fast, they are predictable, and given the same facts they produce the same answer every time. In a regulated setting that reproducibility is not a nice-to-have, it is the thing an auditor asks for. Products like IBM ODM, Drools, Camunda's DMN engine, InRule and ACTICO have decades of production use behind them and they do this job well.
If your facts already arrive complete, structured and trustworthy, a rules engine may be the entire answer. Plenty of teams are in exactly that position, and they should buy one.
What a rules engine assumes
One thing, and it is worth stating plainly because it defines the boundary of the category rather than criticising it: a rules engine is handed a complete record.
Every rules engine, open source or enterprise, begins the same way. Facts go in, rules run, an outcome comes out. The engine is not responsible for where the facts came from, whether they are all present, or what to do when they are not. That is by design, and it is the right design for a component.
The trouble is that in most real operational decisions, assembling the facts is the work. The invoice arrived but the goods receipt was never entered. The applicant uploaded a bank statement as a photograph. The counterparty's registration document is two years out of date. The one person who knows whether the price change was agreed has not replied to the email.
None of that is a rules problem. All of it is between you and the moment the rules can run. So the rules engine sits there, correct and instant, waiting for a case that a person is still assembling by hand.
The decision was never the slow part. Getting to it was.
What about open-source rules engines?
They are a real option and worth taking seriously. Drools is the best known, a mature Rete-based engine with a DMN implementation and a long production history. Others in circulation include Easy Rules, NRules on .NET, and json-rules-engine in the JavaScript world.
The honest trade is the same one as any open-source infrastructure choice. You get the engine for nothing and you own everything around it: the authoring surface your business users will actually use, the repository, the testing harness, the deployment path, the audit trail, and the integrations that feed it facts. Teams that already have platform engineers and want the logic layer under their own control do well with this. Teams that thought they were buying a way for the risk lead to change a threshold usually discover they bought a library.
When do you need more than a rules engine?
Five signals, and one is usually enough:
- The facts arrive as documents. Contracts, statements, certificates, receipts, IDs. If somebody is reading a PDF and typing numbers into a form so that a rule can fire, the rule is not the bottleneck.
- The facts arrive from several places. Your own systems, a registry, a bureau, a KYB provider, a supplier portal. Someone has to fetch all of them and reconcile the versions.
- Some facts do not exist yet. The missing goods receipt, the unsigned approval, the reference that was never taken up. No system holds the answer. A named person does, and they have to be asked.
- A case can be half-complete. If your process has a state between "arrived" and "decided" where it sits waiting on somebody, you have a chasing problem and rules do not address it.
- You need the reasons, not just the outcome. Not only which rules fired, but what evidence each one was reading and where that evidence came from.
How to evaluate one
- Who can actually write a rule? Ask to see the person who owns the policy change one, unaided, in the demo. Not a solutions engineer.
- How do you test a change before it runs? Replaying a candidate policy against your own history is the cheapest honest answer. Ask whether it is possible on your data, not on a sample set.
- What does the audit record contain? Which rules fired is table stakes. Which inputs each rule was reading, and where those inputs came from, is the useful version.
- What happens to an incomplete case? This is the question that separates the products, and it is the one that is least often asked.
- What does it take to go live? Ask for the implementation plan in weeks and the professional-services line in dollars, up front. The licence is rarely the expensive part.
How Floowed does it
Floowed is the decision platform. The Decision Engine is where your rules live, and it works the way the good rules engines work: conditions and actions written by the people who own the policy, versioned, with the rules behind every call recorded against the case. Gates are explicit. A policy change can be replayed against your historical book before it runs, so the impact is known rather than argued about. Given the same inputs, the same policy returns the same outcome, every time.
What we added is everything on the other side of the facts. Floowed gathers them from your systems, from external sources, and from documents at any quality, including the handwritten, photographed and scanned ones that defeat extraction elsewhere. When something is missing, the open gate names what is needed and who can supply it, and the case is chased until it closes. What arrives is a decision-ready case, with the outcome, the reasons, and the evidence each reason was reading.
That is the difference in one line: a rules engine runs your policy. Floowed gets the case to the point where your policy can run, and then runs it.
Your systems stay your systems. We integrate in both directions across 400+ integrations, so the outcome lands back where it belongs and nothing has to migrate. Activation runs in days, not quarters, with no professional-services engagement attached. And Floowed returns the decision and the reasoning behind it; the hand-over point is yours to set.
Frequently asked questions
Is a decision engine just a rules engine with extra features?
No, and the difference is not the rules. Both evaluate conditions against facts. A rules engine is given the facts. A decision engine is responsible for getting them: from systems, from external sources, from documents, and from people who have not answered yet. That responsibility is the product.
Can I use a rules engine for loan decisioning?
For the policy itself, yes, and many lenders do. The part it does not cover is turning a loan file into facts the policy can read: normalising income from payslips, deriving cash flow and DSCR from bank statements, cross-checking a declaration against the document that should support it. See what is loan decisioning for how the pieces fit.
Do I need DMN?
You need what DMN was created for, which is decision logic a business person can read and a machine can execute without a translation step. Whether that arrives as the OMG standard or as a vendor's own equivalent matters less than whether the person who owns the policy can sit down and read it.
What is a rule repository?
The versioned store of your rules, with history, authorship and the ability to roll back. It is what makes a rules engine auditable rather than merely configurable, and it is the first thing to ask about in a demo.
How much does a business rules engine cost?
Open-source engines are free to licence and cost you the platform work around them. Enterprise BRMS products are typically quoted per environment or per core with an implementation engagement attached, and the services line is often larger than the licence. Ask for both numbers together.
See it on one of your own decisions
Book a demo and name the decision you want automated. We will come back with how it runs: what gets gathered, which gates stay open, who gets chased, and what the Decision Engine returns. To try it yourself first, start free.
Related reading: what is a decisioning engine, credit policy back-testing, and turning risk appetite into decision rules.
Last updated 2026-08-26 by Kira.