KreeditePlatformLoan Decisioning Rules
Platform

Your policy on top. Our score as the input.

The engine returns a composite score and a recommendation tier. What each tier means for your product - the rate, the limit, the escalation path, the manual review depth - stays entirely inside your loan-decisioning rules.

Reference instrument
  • Rule engines supportedJSON, DSL, UI
  • Rule versions retainedFull history
  • Approve / Review / RiskConfigurable
How rules layer on

Score first. Rules second. Human review always.

The composite score is deterministic. Your rules are the discretionary layer that turns a score into a decision. Kreedite never replaces your credit policy - it makes it faster to run and easier to defend.

  1. 01
    Composite score arrives

    Every application returns a 0-100 composite with full per-signal attribution.

  2. 02
    Tier assignment

    The score is mapped to one of three tiers - approve for review, manual review advised, or high-risk route - using thresholds your team sets per product.

  3. 03
    Product rules apply

    Interest band, exposure limit, tenor cap, collateral requirement and escalation path are chosen by your rule set - not by the engine.

  4. 04
    Human review

    A queued underwriter completes the decision. The engine's job ends at recommendation - the lending decision is always yours.

Default tier layout
Approve for review
Composite 68 and above

Recommend advancing to underwriter with light review depth. Typical low-friction path for consistent alt-data borrowers.

Manual review advised
Composite 45 to 67

Routed to full manual review. Reason codes highlight where the signal is weak so the underwriter can focus.

High-risk route
Composite below 45

Flagged for a stricter decisioning path. Not an automatic decline - the lending decision remains with your team.

Thresholds shown are Kreedite defaults. Every deployment overrides them per product, per segment, or per market.
Guardrails
  • The engine never auto-approves and never auto-declines - the recommendation is always advisory.
  • Rules are versioned. A past decision can be replayed against the rule version that produced it.
  • High-risk tier routes to stricter review, not to an automatic no.
Configuring rules

Three surfaces, one rule store.

Configure decisioning rules the way that matches your team - through a UI for policy owners, a domain-specific language for underwriting, or JSON for programmatic deployment.

Policy UI

Threshold sliders, tier mappings and escalation paths - built for a credit policy owner who does not want to touch code.

Rule DSL

A readable domain-specific language for underwriting teams. Diffs cleanly in version control, reviews cleanly in change management.

JSON deployment

Programmatic rule deployment for lending institutions running full CI/CD around credit policy - safest path for institutions with tight change control.

  • Every rule change is audited with actor, timestamp and diff.
  • A live rule version is always associated with every scored decision.
  • Simulations can be run against historical applications before promoting a new rule set.
  • Roll-back to a prior rule version is a single operation, not a redeployment.
Next step
Configure the tiers to your policy - not the other way around.