Slow
Decisions wait on lookups and approvals that could have been evaluated the moment the case arrived.
SuTraEnterprise Business Rules & Decision Engine
Automate decisions. Eliminate errors. Ship faster.
SuTra — Smart Unified Transaction and Rule Automation Engine — centralises complex business logic into a configurable decision engine. Author rules visually or in a compiled expression language, test them before they touch production, and govern every change.
The problem
The cost of manual rules.
Every manual decision is a risk. Every spreadsheet lookup is a delay.
Silent
Errors buried in nested spreadsheet logic ship unnoticed, and only surface when someone downstream questions an outcome.
Undocumented
Spreadsheet-based rules leave no audit trail. Reconstructing why a case was decided a particular way becomes archaeology.
Drifting
The same case is decided differently by different channels, because each one carries its own copy of the logic.
How it works
Build, test, govern, execute.
A no-code and low-code platform: author rules visually or in the compiled SuTraExpr language, model matrix logic as decision tables, then test, approve and deploy.
Build
Visual rule builder, or the SuTraExpr expression language.
Test
Real-time simulation in memory, without deploying anything.
Govern
Maker-checker approval with a full audit trail.
Execute
Compiled expressions and decision tables, evaluated at scale.
Visualise
Export flow diagrams for stakeholder review.
SuTra is a deterministic business rules engine. It does not use machine learning to reach decisions.
Authoring
Two ways to write a rule.
Business users build visually. Engineers write expressions. Both compile to the same engine and mix inside one workflow.
Visual rule builder
Complex logic assembled without writing code.
- Unlimited AND/OR nesting, to whatever depth the rule needs
- Drag and drop reordering across rules and groups
- Configurable field filters with data types and operators
- Live expression preview as conditions are built
SuTraExpr
A sandboxed, compiled expression language that reads like the business rule it represents.
- Business-readable syntax, roughly half the size of the equivalent code
- Compiled on publish, invoked from cache at runtime
- Sandbox-safe: reads facts and computes, with no arbitrary code or I/O
- Autocomplete, type checking and validation before go-live
Computed outputs
A rule defines what happens when it passes, including calculated fields — a formula such as BMI = Weight / (Height × Height) is evaluated during execution. Derived facts accumulate across a chain, so the output of one rule becomes the input to the next.
Beyond single rules
Matrix logic and multi-step reasoning.
Decision tables
- Hit policies: first, unique, priority, any, collect, sum, min, max, count
- Operator cells such as ≥ 45, between 18 and 44 and catch-all
- Each row compiles to its own predicate
- Multi-match violation detection
Forward chaining
Given these facts, what can we conclude?
- Rules evaluated in execution order
- Each passing rule adds derived facts
- Later rules see accumulated facts
Backward chaining
What do we need in order to prove this goal?
- Works backwards from a goal to its proof
- Resolves missing facts from provider rules
- Cycle detection prevents infinite reasoning
Test and simulate
Nothing reaches production untested.
Any rule can be compiled and run against real data before it is saved — in memory, with no deployment and no database writes.
- Compile and run without saving to the database
- Upload test facts as CSV, in vertical or horizontal format
- Instant pass or fail with execution timing
- Derived facts shown as the engine resolved them
- Expression errors reported with actionable diagnostics
- Batch execution across hundreds of records with live progress
- Execution history
Per-rule execution counts with pass and fail tracking, filterable by date, user and mode. - Full input capture
Every run keeps the input facts, so any result can be reopened and understood. - Replay
Historical inputs can be re-run through current rules to detect drift before a change goes live. - Correlation
Every execution is tagged with an id, searchable by correlation or caller reference.
Use cases
Where insurers put it to work.
The same engine, configured differently, across the operation.
Underwriting eligibility
STP / NSTP determination
Product eligibility
Customer validation
Policy validation
Payout eligibility
Premium collection validations
Document completeness checks
Operational routing
Approval determination
Data quality validations
Governance
Changeable by the business. Answerable to audit.
Only published rules execute, so untested logic cannot reach production.
Draft
The author builds and edits.
Review
Submitted to the checker queue.
Approved
A checker verifies the logic.
Published
Live in production, and only then.
Role-based access
Maker, checker, admin and viewer roles with department ownership. Rejected rules return to draft with the reviewer's comments attached.
Versioned definitions
Immutable rule snapshots plus full approval history — who changed what, when and why. Roll back to any previous version.
Effective dating
Changes take effect from a date you choose, so cases evaluated earlier still resolve against the rules that applied then.
Pluggable log store
Execution logs held in SQL by default, or externalised to object storage with the metadata kept indexed for search.
Architecture
Called like any other service.
Every feature is reachable through documented REST endpoints, so calling systems hold no rules logic of their own.
Presentation
Visual rule builder
Execution console
Test and simulate
Flow export
API gateway
REST
JWT authentication
HMAC signature
Rate limiting
Application
CQRS
In-memory cache with automatic invalidation
Background log writer
Rule engine
Forward chaining
Backward chaining
Rule orchestrator
SuTraExpr compiler
Decision tables
Deployment
On-premises
Cloud native
Hybrid
.NET
SQL Server / Azure SQL
In the SolTech ecosystem
The decision layer under every platform.
SuTra is used directly by insurers, and by the rest of the SolTech portfolio.
- Insight Underwrite — evaluates underwriting eligibility and STP or NSTP determination.
- PayLifPro — evaluates payout eligibility and pre-payment validation rules.
- SolServ Studio — drives routing, eligibility and approval determination.
- EzBilling One — evaluates collection, campaign and processing rules.
- InstaDocs — supports metadata, document and process validations where applicable.
What changes operationally
Rule changes without releases
Business teams adjust thresholds and conditions through configuration.
One answer everywhere
The same rule returns the same decision to every calling system.
More straight-through processing
Cases that meet the rules clear without touching a queue.
Defensible decisions
Every outcome can be reproduced with the rule version that produced it.
Which rules are costing you a release cycle?
Bring us one process where business logic keeps changing, and we will show you what it looks like configured in SuTra.