v2.0

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

Watch the launch videoWatch

Loan origination software
moves the file. GoRules decides.

GoRules is not a loan origination system. It is the decision layer inside the one you already run: knockouts, overlays on your AUS findings, affordability, stipulations, and pricing modeled as visual decision tables your credit team edits, evaluated in milliseconds with every rule that fired attached.

From stipulation to waiver,
start to finish.

Watch six days of one loan from the borrower side: a paystub the bank feed already proved, a one-cell change to the documentation policy, a replay across 3,400 funded loans, a signed release - and 2.3 days off time to close.

scroll to play
Day 6, 09:41

She is waiting on a piece of paper.

Nadia Haddad asked for $38,400 of home improvement credit. Identity cleared, payroll linked, income verified from the bank feed on day one. The app still wants a paystub - and thirty-four other borrowers are stuck on the same screen.

The requirement

Income verified. Still asking for paper.

The bank feed matches the employer exactly, 24 months of deposits, 1.8% variance against stated income. One open stipulation holds the loan: proof of income, awaiting upload.

One cell

The stipulation becomes a waiver.

The blocking rule opens the live documentation policy. For bank-verified income under $50,000 in risk band A or B, required docs go from a paystub to none - on a branch, every other income source untouched.

Proof before production

3,400 funded loans replay.

A year of funded files re-runs against the draft while you watch: 41% would have skipped the stipulation, none of them with an income mismatch above 5%, fraud and identity checks unaffected.

Sign-off

Credit Ops approves. v5.2.0 ships.

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

Same day, 16:20

The upload request disappears.

Open paystub stipulations re-evaluate: Nadia sees approved, funds Tuesday, and 23 other borrowers move the same day - except the one whose bank income misses stated by 12%. Time to close: 11.2 days down to 8.9.

The workflow is bought.
The decisions are welded in.

Loan origination software is sold as one system for the whole pre-funding lifecycle: application intake, document collection, verification, underwriting, credit decision, quality control, closing, and funding. Most platforms do that job well, and the file has to live somewhere. The part that ages badly is the decisioning inside it: score floors, DTI caps, lender overlays stacked on top of Desktop Underwriter and Loan Product Advisor findings, reserve and documentation requirements, stipulation logic, counteroffer terms, and referral routing. That policy is either hard-coded in a platform your credit team cannot open or held as vendor configuration only the vendor understands.

So the change nobody argues about takes a quarter to ship. Moving a DTI overlay two points, adding a reserve requirement for a new investor, or routing self-employed income to manual review becomes a professional services ticket, a change-order fee, and a release window. While that request sits in a queue the policy is already live somewhere else: a spreadsheet the credit team maintains and an email chain of approved exceptions, which quietly become the real system of record and are invisible to leadership and audit alike.

The market answer is to replace the whole platform. Almost every ranked comparison of loan origination systems is published by a vendor that puts itself at the top, and the migration on offer runs six to eighteen months of re-implementation and parallel running across ops, underwriting, and servicing. That is a rip-and-replace to solve what is really a rules problem. Nothing about your intake, e-sign, or funding flow needed to change.

And the questions that follow a decision do not care which vendor you picked. Which policy version declined this application in March, who approved that threshold, and what were the specific principal reasons? Regulation B requires principal reasons that are both specific and accurate, and CFPB Circular 2023-03 is explicit that algorithmic complexity is no excuse for vague ones.

Keep your LOS.
Upgrade the decisions.

GoRules is not a loan origination system and has no ambition to become one. It owns the decision points your LOS calls, and nothing else.

01

Every decision point in origination, in one graph

Prequalification and eligibility, knockout screens, overlays on top of the AUS finding, affordability math, collateral and LTV limits, stipulations, counteroffer terms, exception routing, and the pre-funding quality control checks are all decisions, and they are all modeled the same way. Decision tables carry the matrices, ZEN expressions handle derived values like DTI and residual income, and typed TypeScript function nodes cover anything custom. One call returns one structured result: outcome, price, stipulations, reason codes, and the queue to route to.

02

Loan underwriting rules the credit team actually edits

Loan underwriting policy is a matrix, and a decision table is that matrix, edited by credit and risk without an engineering release. Natural-language rendering makes each row read like the credit policy document, so the analyst writing it, the officer approving it, and the examiner reading it look at the same artifact. GoRules AI can draft a rule change, run the test suite, and explain why a file decisioned the way it did; it never releases anything. Git-like version control, approval workflows, and one-click rollback mean risk signs off before production sees a change.

03

Beside your LOS, not on top of it

Your LOS keeps owning the application, the documents, the disclosures, and the funding instruction. It calls GoRules over REST wherever a decision is needed, or your own service embeds the MIT-licensed open-source ZEN engine and evaluates in-process. The payload is the loan file you already model, with bureau attributes, income calculations, AUS findings, and model scores arriving as plain inputs, so the outcome stays deterministic and readable even when a score is not.

Four weeks,
not four quarters.

No data migration, no parallel run, no retraining your closers. The system of record does not move.

01

Connect at the decision points

Map where your origination flow already asks a question: prequalification at the point of sale, the credit decision after verification, stipulation generation, exception routing, and the quality control gate before funding. Each becomes a REST call to GoRules from your LOS workflow or middleware, or an in-process evaluation via SDKs for Node.js, Python, Java, Go, C#, and Rust.

02

Model the policy you already have

Rebuild the overlay matrix and the credit policy document as decision tables and graphs, per product and per investor, instead of one global setting. Bureau attributes, AUS findings, and model scores stay inputs, so nothing in your scoring or verification pipeline changes.

03

Simulate against closed files

Branch the policy, make the change, and replay a quarter of historical applications through both versions. Compare the approve, refer, and decline mix and the straight-through rate before anything reaches production, then trace a single file through every node to see exactly which rule moved it.

04

Promote and operate

Push through dev, staging, and production with an approval recorded at each step. Every evaluation returns the outcome plus the exact rules that fired, ready for your stipulation letters and your adverse action process. Iterate weekly instead of quarterly, and roll back in one click.

Built for production,
not proof of concept.

  • Sub-millisecond evaluation with the open-source ZEN engine (Rust core, MIT), embedded in your services or called over REST: fast enough for instant prequalification at the point of sale
  • Git-like version control on the credit policy: branches, commit history, approval workflows, and one-click rollback, so an overlay change ships without a vendor change order
  • Self-host with Docker or Kubernetes so borrower PII, bureau pulls, and income documents never leave your infrastructure, or run on GoRules Cloud
  • Full traceability: every decision links to the rule version that produced it, and every change records who edited what and when. SSO, role-based access control, and SOC 2
  • No lock-in: the core engine is open source under MIT, and 70+ industry templates, including loan approval, mean you start from a working policy instead of a blank editor

Questions, answered.

What is loan origination software?

Loan origination software manages the pre-funding stages of a loan: application intake, document collection, verification, underwriting, the credit decision, quality control, closing, and funding, after which a loan management or servicing system takes over. Vendors bundle two very different things under that name: a workflow engine that moves the file between people and states, and a decision engine that applies credit policy to the data on it. The workflow part changes rarely. The decision part changes every time credit conditions, an investor guideline, or an overlay moves, and GoRules is only that second part.

Is GoRules a loan origination system?

No, and this page would be dishonest if it implied otherwise. A loan origination system owns the loan file: intake, document management, disclosures, e-sign, integrations with bureaus and appraisal vendors, and the funding instruction. GoRules holds no loan file and runs no workflow. It is the decision layer your LOS calls whenever it needs an outcome, which means rigid decisioning is fixable without a platform migration.

What is the difference between a loan origination system and a decision engine?

An LOS orchestrates: it knows which stage a file is in, who owns it, what documents are missing, and what happens next. A decision engine decides: given this borrower, this collateral, and these bureau and AUS attributes, does the file approve, refer, or decline, on what terms, with which stipulations and reason codes. Bundling them means a workflow change and a risk-threshold change touch the same configuration, ship on the same release, and queue behind the same approvals, for two concerns with nothing in common. Split them and the workflow can stay stable while policy moves weekly.

Which loan underwriting decisions can GoRules automate?

Anything expressible as policy rather than judgment: eligibility and knockout screens, minimum score and bankruptcy or foreclosure seasoning, DTI, LTV, CLTV and reserve overlays layered on top of AUS findings, income and documentation requirements by employment type, affordability and residual income calculations, risk-based pricing tiers, stipulation generation, counteroffer terms, and referral routing. Clean files go straight through. Borderline files route to a human underwriter with the triggering rules attached, so the reviewer starts from the reason instead of from scratch. The judgment calls stay with your underwriters; the repeatable calls stop consuming their day.

How does GoRules support adverse action notices and exam requests?

Every evaluation returns the specific rules that fired, so a decline or a counteroffer arrives with its actual principal reasons rather than an opaque score, and your team maps those to the notice language Regulation B and the FCRA require. Version control lets you reproduce the exact policy version that decided any historical file, along with the author and approver of the change that put it there. That is the record an examiner or internal audit asks for when reviewing overlays and exceptions. GoRules supplies the traceability; the compliance obligations, notice content, and fair lending testing remain yours.

The same engine,
next door.

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

Keep the system of record.
Take back the decisions.

Pick one decision point, your DTI overlay is the usual first, rebuild it as a decision table, and replay last quarter's files through it before anything touches production.