Real-time decisioning
Straight-through decisions. A request arrives, a decision flow runs, an answer comes back in milliseconds - built and changed by the risk team, not by a release train.
The artifacts, not a black box
Decision logic is made of named artifacts - each one something you can open, review, test and version.
Rule sets and decision tables
Business rules comparing numbers, text and dates - including starts-with and ends-with matching - and decision tables with open and closed intervals that read like a spreadsheet and execute like production code, with overlap and gap validation a spreadsheet can never give you.
Decision trees and scorecards
Branching logic and scoring, with every predictor contribution to a final score available in the explanation afterwards.
Custom functions
Mathematical formulas for the calculations that do not fit a table. Built in an editor rather than written as code, and kept inside the decision flow rather than hidden in an application.
Imported ML models
Bring a trained model, call it as part of the flow, and keep the surrounding policy, cut-offs and manual overrides in the same place. No two-quarter productionisation project.
Data lookups in parallel
Bureaus, fraud scores, device checks and your own services over REST and JSON or XML, called in parallel inside the flow, mapped in with JSONPath, with timeouts and fallbacks.
LLM and agent calls
Language model and agent calls with guardrails, where judgement helps - governed as versioned artifacts, not a prompt typed into a box.
From an idea to a decision in production
Elsewhere this path runs through a rules engine, a spreadsheet, a wiki, a ticket tracker, a test script somebody wrote and a log aggregator. The seams between them are where the risk lives.
| Stage | What the platform does |
|---|---|
| Author | Visual decision flow builder, with reusable components shared across flows and champion/challenger forks built in |
| Test | Unit tests on every artifact, test data generated from the logic’s own thresholds, decision table overlap and gap validation |
| Regress | Save a real run as a test case, then re-run the whole suite after any change and see what moved, against which expectation |
| Assess impact | Run a scenario set through the current and the proposed logic before deploying, and see which decisions change and by how much |
| Compare | A computed entity-by-entity diff between the deployed release and the next one - not a changelog somebody remembered to write |
| Approve | Configurable sign-off sequences. A release reaches production through the approval process you defined, by the people you named |
| Release | Versioned, compiled release snapshots with generated notes and full lineage |
| Execute | The same decision flow in real time at regional endpoints and in batch over FTP, S3 or GCS |
| Trace | Every execution can be opened and read: which rules fired, on which values, what each model scored |
| Revise | Full revision history on every entity - who changed what, when, and what it said before |
The value is the absence of seams
You did not assemble this from six tools, so there is no gap for a change to slip through. The logic you tested is the logic that was approved, is the logic that was released, is the logic that ran, is the logic you can read back six months later.
Execution
Same decision flow, every mode. Batch and real time cannot drift apart, because they are not two implementations.
- Regional endpoints. Real-time REST endpoints, in the region you choose, for latency and for residency.
- Batch over FTP, S3 or GCS. The nightly portfolio rescore runs the same decision flow as the application-time decision.
- Execution in your own environment. An execution node can run in your own infrastructure on request; the design authority stays in the portal.
- Ordinary integration. REST and JSON in, REST and JSON out. One call from your core system.
Questions we get asked
How fast is a decision?
Milliseconds for a flow that evaluates rules and models locally. What dominates real-world latency is the external data you call - a bureau or fraud provider - which is why lookups run in parallel inside the flow, with timeouts and fallbacks you control.
Do we need engineers to change a rule?
No. That is the point. Risk analysts and policy owners build and change decision logic in the portal, test it, and put it through approval. Your engineers integrate once, with a single REST call.
How is this different from the rules engine we already have?
Most classic engines gave the rules to IT. They also have no built-in regression testing, no impact analysis, no computed release diff, and no trace a non-engineer can read. Those are the parts an auditor asks about.
Can we prove a change is safe before it ships?
Yes, and this is the part teams usually cannot do today. Capture regression tests from real runs, run impact analysis across a scenario set to see which decisions would change, read the release-to-release diff, and put a new policy live as a challenger before it becomes the champion.
Do batch and real time use the same logic?
Yes. They are the same decision flow, so the nightly rescore and the application-time decision cannot drift apart. Elsewhere they usually do, because different people built them at different times.
Can we bring our own model?
Yes. Import a trained model and call it as part of the flow, with the policy rules, cut-offs and overrides around it in the same place.
Decisions that take days, not milliseconds
Some decisions cannot be answered in one request: evidence arrives over days, out of order, and sometimes wrong. That is a different shape of problem, and it has its own product surface.