Operations Portal

Run every loan, every program, from one keyboard-first command center

The all-day console your underwriters, funders, CS agents, and dealer-relations team live in. Dense, fast, and built on one rule: there is no god-mode. Every override carries a typed reason, proof, step-up auth, and an audit entry designed to be append-only.

Book a demo → See the platform

One source of truth. No split-brain.

Legacy ops consoles compute their own numbers, so the screen and the system of record drift apart. OneApp Finance doesn't. Every number you see, whether SLA age, APR, payment, reason code, or funding state, is computed by the Core and rendered by the portal. The console never recalculates, so a bug in a screen is a display defect, never a wrong decision. One ledger, one truth, every desk.

The command center

Queues, underwriting, and funding on one screen

Queues are the home screen: assignable, prioritized work routed from every domain by the Core, with status chips and SLA age rendered straight from the system of record, never timed in the browser. Open a deal and you land in the cockpit; the funding console next door is the most controlled desk on the platform. It's keyboard-complete: jump rows, open a deal, and run any action from the command palette without reaching for the mouse.

Seven routed work types: underwriting, fraud, stipulations, funding, boarding rejects, complaints, and exceptions, each routed by the Core and never hand-sorted. Compliance-halt and SLA-breach boards derive automatically, so nothing stalls in silence.
The decision card: outcome, model score, pricing tier, principal reason codes in plain Reg-B language, and the exact policy and model version that ran. Hit Replay and the decision is built to re-run bit-for-bit against its frozen snapshot. You prove what happened, you don't reconstruct it.
Dual-control funding: the person who requests a disbursement is never the person who approves it, designed so the Core resolves maker/checker on actor IDs. That's structural, not a UI setting. The compliance gate before funding is built to be non-overridable, and raw bank return codes pass through intact because some carry disclosure obligations.

What you get

"Assigned to me" as the default view; saved views carry their program scope, so a shared link opens at the right scope for the next person.
Adverse-action by pick-list: manual declines select Compliance-owned principal reasons. There is no free-text reason field anywhere, so a vague "score too low" simply isn't on the list.
Champion vs. challenger: shadow models score the same case and show their would-have-been outcome as an informational strip the underwriter cannot adopt.
A call-in override can satisfy only the overridable borrower-confirm leg, never a floor gate, and it lands in the audit trail.

No god-mode

Every override carries a reason, proof, and a record

This is the line that separates OneApp Finance from the consoles that came before it. There is no waive button. Every act that advances a file past a gate is designed to run the same override grammar, the structural mirror of the borrower's own affirm. The hard floor renders identically everywhere: visibly locked and stated, never quietly removable.

Typed reason, not free-text: reasons come from a Core-owned taxonomy plus a minimum-length justification. No anonymous bypasses.
Proof where policy requires it: an attestation states what you did, why, and the proof reference, written immutably into the journey.
Step-up re-auth for high-impact acts. The riskiest actions are designed to re-challenge the actor before they commit.
Close-the-loop audit entry. Every override appends a new, hash-chained, actor-stamped timeline entry that renders inline. There is no "skipped" state to hide in.

Why it holds

The floor is a derived predicate, not a hand-named list, so a gate can't quietly fall out of the protected set.
Floor gates aren't even offered an override; the Core is built to re-perform them regardless of what any screen claims.
Reasons stay in their lane: the borrower sees a regulated notice channel, the dealer rep sees only "not approved," and reason codes never leak to the wrong audience.
An override is evidence, never god-mode: the record it writes is the audit substrate a fair-lending exam reads.

The separations that hold

Two-person controls, resolved on the human, not the hat

Maker ≠ checker

One person can't both create and approve money movement. The check resolves on actor IDs, so stacking roles never lets one human take both sides.

Granter ≠ doer

Granting access is its own authority. No one can grant themselves an operational power; that's the canonical floor violation, rejected.

Author ≠ activator

The person who authors a config change, decision table, or model can't be the one who activates it, including the admin editing the role model itself.

No break-glass

There's no emergency single-person path. The answer to a staffing gap is staffing, with a fail-closed fallback, not a backdoor.

Dealers, complaints & reports

Govern dealers and stand behind your numbers

The dealer directory tracks standing through a six-state machine: prospective, active, probation, hold, suspended, terminated. The machine can freeze and propose on hard signals, but only the dealer-risk role disposes a formal change, with maker separate from checker. Complaints are first-class Remediation Cases anchored to the borrower's evidence, and every chart reads the same Core-owned event log the queues mutate, so the dashboard and the system of record can't disagree.

Auto-hold, human dispose: hard signals trigger an immediate, reversible, SLA-bounded hold. No machine ever auto-suspends a dealer; that's a human verdict with due process.
Complaints anchored to the borrower. A Remediation Case carries its own immutable record and never routes through the dealer it implicates.
One source, two views. Reporting is a read-projection of the same Core the queues write to. The portal renders totals; it never computes its own.
Drill to the deal. Click any chart, land on its filtered grid, open the cockpit. The number and the underlying loans never split apart.

In an exam

Standing is per program, so a suspension in one program doesn't silently touch another.
Complaint and dispute rates feed the dealer risk score; a band breach proposes a standing change, but a person disposes it.
Funnels count unique deals by lineage; raw application count is only a labeled "attempts" metric.
Access itself is a report: the same hash-chained spine backs the journey timeline and the audited-read log, so who-saw-what is reportable.

Straight answers

Operator questions, answered plainly

Can an admin just push a loan through?

No. There is no god-mode and no waive button. Advancing past a gate runs the override grammar: typed reason, proof, step-up where required, and an immutable audit entry. Floor gates aren't even offered an override; the Core is built to re-perform them regardless.

Why won't my dashboard ever disagree with the system?

Because reports read a Core-owned projection off the same event log the queues mutate. The portal renders numbers; it never computes them. One source of truth, no split-brain.

Can the same person request and approve a disbursement?

No. Maker can't be checker, designed so the Core resolves maker/checker on actor IDs. That's structural, not a UI setting. Both must hold the funding department in the same program, and they must be two distinct people.

Does Compliance process loans?

No. Compliance gate-keeps. It can read across every department in its program, place a hold, and review overrides, but it never decisions an application, clears a stip, or emits a draw.

Go deeper

See it live

See your whole operation on one screen

Book a demo → Explore the platform

Walk through the queues, the decision card, and a dual-control funding approval with our team.