v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch
gorules
Book a demoGet started

Credit decisioning software.
Your model scores, your team decides.

GoRules is the decision layer where credit policy lives: score cutoffs, knockout rules, overrides, and risk-based pricing in visual decision tables your risk team edits directly. Change the policy the same day, without retraining a model or waiting on an engineering release.

One policy change,
start to finish.

Watch a real afternoon in a lending team: a referral bottleneck, a one-cell policy fix, a simulation over 1,240 historical applications, a signed release, and a queue that drains itself.

scroll to play
Tuesday, 14:02

Applications keep coming.

APP-2481 lands in the underwriting queue: personal loan, $15,000, FICO 651, thin-file. Under the current policy it is about to join a long line.

The case file

Everything checks out. Still referred.

Bureau data verified, income solid, DTI under the cap - and APP-2481 still lands in manual review. The reason lives in the policy.

One cell

The head of credit fixes it herself.

The failing rule opens the live policy. The floor drops from 660 to 640 - on a branch, DTI guardrail untouched.

Proof before production

1,240 applications say yes.

Last month's volume re-runs against the draft while you watch: 86 approvals swap in, zero guardrail breaches, referral queue projected down 14 a day.

Sign-off

Risk approves. v4.2.0 ships.

Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away.

Same afternoon

The queue drains itself.

The change lands back in the workbench: referrals flip to auto-approvals - except the one the DTI guardrail still holds. Auto-decision rate: 61 to 84 percent.

Cutoffs live in code.
Changes take sprints.

Most lenders do not have credit decisioning software. They have a scoring model on one side and hardcoded policy logic on the other: cutoffs buried in application code, knockout rules copied across services, overrides living in a spreadsheet the underwriting team emails around. Moving a score cutoff from 640 to 660 for one segment is a business decision that takes an afternoon to make and a sprint to ship, because it sits in a codebase the credit team cannot touch.

The alternatives on the market do not fit either. Enterprise decisioning software suites are built around months-long implementations and bundle bureau connectors and data marketplaces you already have through your feature store and LOS. Search for credit risk software or credit risk management software and many of the results are accounts-receivable tools for trade credit, not risk decisioning platforms for lenders.

And the in-house rules service your engineers built has no simulation, no approval workflow, and no answer when internal audit asks who changed the DTI threshold in March and what it did to approvals.

The pressure is not only operational. Regulators expect every automated decline to trace to specific, accurate principal reasons, and "the model said so" is explicitly not acceptable. If your policy logic is scattered across code, you cannot show an examiner the exact rules that fired on a given application, and you cannot prove who approved the change that put them there.

The decision layer
between score and outcome.

Your feature store serves the model, the model emits the score, and GoRules turns that score into a governed decision - with the policy in tables your credit team owns.

01

Credit policy as decision tables your team owns

Credit policy is naturally a matrix: score band by DTI by LTV, resolving to a decision, a limit, and a price. GoRules decision tables are that matrix, spreadsheet-style, edited by credit analysts and rendered in natural language for review. Knockouts and overlays are modeled with Policies, ordered blocks evaluated in sequence, so hard declines like active bankruptcy fire before the score is ever consulted, and referral routing sends edge cases to an underwriter instead of forcing a binary outcome.

02

Champion and challenger before anything touches approvals

Branch the live policy with git-like version control, make the challenger change, and run the same set of historical applications through both as test cases to compare decisions before rollout: which applications swap in, which swap out. GoRules AI can edit rules, run tests, and explain the resulting decisions while you iterate. When the challenger wins, promote it through dev, staging, and production as a versioned release with required approvals, and roll it back in one click if the portfolio disagrees.

03

Decisions that explain themselves

Every outcome traces through readable rules: which knockout fired, which cutoff row matched, which pricing tier applied. That trace is what lets your team map declines to the specific principal reasons adverse action notices require, instead of reverse-engineering a black box. Behind it sits the governance record model risk and internal audit ask for: full audit logs, commit history, approval workflows, SSO, and role-based access control.

From score
to decision.

GoRules does not replace your feature store, your model, or your LOS. It is the layer between score and outcome.

01

Wire it into the flow you already have

Your LOS or origination service calls GoRules over the REST API, or embeds the MIT-licensed open-source ZEN engine directly via SDKs for Node.js, Python, Java, Go, C#, and Rust. The request payload carries applicant data, bureau attributes, and the score or PD your model emits, whether that model is fed by Feast, Tecton, Hopsworks, or Databricks.

02

Model the policy visually

Build the decision graph: knockout Policies first, then cutoff tables per segment and product, risk-based pricing tiers, and a decision waterfall ending in approve, decline, or refer. ZEN expressions handle derived values like DTI, and typed TypeScript function nodes cover anything custom.

03

Simulate, then compare

Run historical applications through the simulator against the current policy and a challenger branch, compare the decisions and the rule diffs, and let stakeholders review rules in natural language before sign-off.

04

Release and operate

Promote through environments with approvals, evaluate in production in under a millisecond, and keep every decision and every rule change in the audit log. When credit conditions move, the risk team edits the table and ships the same day.

Built for production,
not proof of concept.

  • Sub-millisecond evaluation with the open-source ZEN engine (Rust core), embedded in your stack or called over the REST API
  • Git-like version control on every policy: branches, commit history, approval workflows, one-click rollback
  • Complete audit trail of who changed which rule, when, and what was decided - the record internal audit and examiners ask for
  • Self-host with Docker or Kubernetes so applicant PII never leaves your infrastructure, or run on GoRules Cloud
  • Enterprise controls throughout: SSO, role-based access, SOC 2, and multi-environment promotion across dev, staging, and production

Questions, answered.

What is credit decisioning software?

Credit decisioning software applies an institution's credit policy to applicant data and risk scores to return approve, decline, or refer outcomes in real time. It is distinct from the scoring model: the model estimates risk, the decisioning layer decides what to do about it - cutoffs, knockout rules, overrides, limits, and pricing. GoRules provides that layer as visual decision tables and graphs that credit teams edit directly.

Is a credit decision engine the same thing as credit decisioning software?

Yes - credit decision engine, credit decisioning engine, and credit decisioning software all describe the same layer: the system that executes credit policy against applicant data and scores in real time. Vendors differ in what surrounds that engine. GoRules pairs the open-source ZEN evaluation engine with the management layer lenders need around it: visual editing for credit teams, simulation, versioned releases with approvals, and a full audit trail.

What is the difference between a credit scoring model and a credit decisioning platform?

A scoring model turns applicant features into a number, typically a score or probability of default, and changing it means retraining and revalidation. A credit decisioning platform consumes that number and executes policy: where the cutoff sits, which applications are knocked out, who gets referred, what price each tier pays. Keeping the two separate means cutoff and policy changes are business decisions, made in minutes, not MLOps projects.

How does GoRules work with ML models and feature stores like Feast or Tecton?

Your feature store serves features to your model, your model emits a score or PD, and your application passes that output to GoRules along with applicant and bureau data. GoRules evaluates the policy against it and returns the decision. Nothing in your scoring pipeline changes, and GoRules never needs access to your feature store or training data.

How does automated decisioning support ECOA and Regulation B adverse action requirements?

Regulation B requires specific, accurate principal reasons for every decline, and CFPB Circulars 2022-03 and 2023-03 make clear that neither algorithmic complexity nor sample-form checklists excuse inaccurate reasons. Because GoRules decisions trace through readable rules, your team can map each decline path to the actual reasons behind it, and the audit trail shows exactly which rules fired. GoRules does not make you compliant by itself; it gives your compliance work the traceability it depends on, which matters equally under FCRA notice duties, model risk management guidance, GDPR Article 22, and the EU AI Act's high-risk classification of consumer creditworthiness systems.

Can GoRules be self-hosted so applicant data never leaves our infrastructure?

Yes. Deploy the full platform with Docker or Kubernetes inside your own network, or embed the MIT-licensed open-source ZEN engine directly in your services, so evaluation happens in-process and no applicant data crosses a vendor boundary. GoRules Cloud is available when self-hosting is not a requirement.

The same engine,
next door.

One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail.

Loan DecisioningApplication to priced decisionTransaction MonitoringThe same decision layer for AML rulesDecision EngineWhat it is and when you need one

The score is your model's job.
The decision is yours.

Start from the loan approval and credit limit templates, wire in the score you already produce, and ship your first cutoff change this week.

Get started Book a demo