Launch your lending program without launching an engineering ticket
Config Studio is where you stand up and run your lending program. Author products, rate cards, credit rules, workflows, vendors, branding, and disclosures in no-code editors. Every change runs one governed pipeline with a full audit trail. You can tighten the rules; you can't break the floor.
Your program, not a template.
OneApp Finance arrives as a full origination engine: decisioning, funding, identity, disclosures, and the compliance rails are all there. What it doesn't ship with is someone else's products, rate cards, credit policy, or vendors. That neutrality is the point. The platform runs your program exactly the way you define it, and Config Studio is where you define it, fast and without code.
- No presets, no lock-in. Nothing comes pre-loaded with another lender's products, rates, or vendors, so the platform bends to your business instead of the other way around.
- Live without an engineering ticket. No-code editors stand up your products, rate cards, credit rules, workflows, and disclosures, and let you change them just as fast.
- What you author is what runs. The Studio writes a versioned config the database stores and enforces, so the screens stay true to what you set.
Yours to define
- Products, pricing tiers, and rate cards
- Credit rules and decisioning logic
- Vendors for bureau, identity, e-sign, and funding
- Branding and disclosures, under version control
Six editors. One operator. Zero deploys.
Each capability has its own authoring screen. You edit what your scope is allowed to own, and nothing else shows up. Editing authority is partitioned into named roles, and every edit is change-control evidence the moment it is saved.
- Products and rate cards. Author products, pricing tiers, term grids, and funding rules. Version every change and roll any of them back.
- Credit rules and decisioning. Build decision logic as business-readable decision tables with typed comparisons, ranges, and set checks. No free-form code, so every rule stays readable and safe to simulate.
- Workflows and step ownership. Decide which steps run, in what order, and who owns each one. Non-delegable steps can't be quietly handed off.
- Vendor catalog and selection. Author shared connections once, then have each program select and layer its own policy on top.
- Branding and white-label. Color inputs, logos, an allowlisted font, a radius lever, light or dark. That is the entire white-label surface.
- Disclosures and copy. Legal-bearing, so they open author-only and route to counsel for sign-off before they can go live.
What you author
- Products, pricing tiers, term grids, and funding rules.
- Credit policy as readable, simulatable decision tables.
- Workflows, step ownership, and non-delegable steps.
- Vendor connections selected and governed per program.
- Brand skin: colors, logos, font, radius, light or dark.
- Disclosure templates and consent screens, counsel-gated.
Nothing with teeth reaches production by hitting save
Free settings like brand tokens publish directly. Everything that matters runs this identical pipeline, every time, with full version history and an immutable audit trail.
- Draft. Edits accrue against a private change-set. The diff against what's live is always visible.
- Validate. A publish gate runs its reject rules. An invalid or below-floor draft cannot advance. It's a hard stop, not a warning.
- Simulate. Pricing, decisioning, and workflow drafts run a synthetic-borrower suite and show the behavioral delta before and after.
- Dual-approve. The author submits; a different person approves. One user ID can't do both. Legal-bearing changes need two counsel approvals.
- Schedule & publish. Approval schedules the change, now or on a future effective date. Publish mints a new immutable version and snapshot.
- Rollback. Re-point to a prior version. It's a governed, dual-controlled, logged publish, never a destructive undo.
Every change is evidence
- An immutable audit trail records who, what, and when.
- Below-floor drafts are rejected server-side at publish.
- The design separates author and approver at the data layer.
- A no-overlap rule guarantees one resolvable value per item.
- Nothing is ever erased; rollback is itself a governed publish.
You can tighten the rules. You can never relax them.
Beneath every knob sits a compliance floor of 16 frozen invariants built so the Core re-performs them structurally, independent of how the deployment is configured. Floor controls aren't hidden. They render as visible, locked controls with no edit path. Floor membership is derived from a shared safety predicate, so a new or mis-classed compliance gate is locked by category, by default, rather than slipping through.
- Tighten, never loosen. You can always make a rule stricter than the floor. You can never make it looser.
- Changes apply to new applications only. When an application is created it captures a frozen snapshot of the whole config set and runs against that copy for its entire life.
- In-flight loans are pinned. Publish a new rate card or workflow tomorrow and every loan already in motion runs against a pinned snapshot, so a new publish doesn't reach it.
The anti-"changed it out from under the borrower" guarantee
- One frozen snapshot per application: workflow, ownership, stips, decisioning, vendor, brand.
- An in-flight loan resolves against its pin, never the live settings.
- Each snapshot is a content-addressed, diffable, rollback-able reference.
- The rare must-migrate change is blast-radius-previewed, approved, and applied under audit, one loan at a time.
Every setting tells you who can change it and how
Every knob resolves to one of four governance tiers, from a free setting you publish directly to platform law that nobody can edit at all.
Free and governed
Brand tokens and copy publish directly. Term grids, funding rules, and vendor picks are editable with a warning and need an approver before they go live.
Counsel-locked
Disclosure templates, finance-charge treatment, and reason-code maps open read-only with a counsel-lock badge. Edits route to counsel and Compliance with dual control.
Platform law
The borrower-authorization gate, money-movement safety, and the invariant registry render as locked controls with no edit path. They're built as code, not config.
The honest answers
What it actually means to run a program on a platform you can tighten but never weaken.
Do I need engineering or a vendor change request to launch a program?
If I change a rule, what happens to loans already in progress?
Can I loosen a compliance rule if my program needs to?
Can one person make a risky change and approve it themselves?
What if I make a mistake?
What you author, and where it runs
Compliance
The locked floor your editors sit above: the 16 frozen invariants and four override tiers you can tighten but never relax.
Explore →Operations Portal
Where the products, rate cards, and workflows you author actually run, with every number computed by the Core, not the screen.
Explore →Developers
The same governed, versioned config reachable through the API, with events and signed webhooks so changes are observable downstream.
Explore →See your program go live
We'll walk you through authoring a product, a credit rule, and a disclosure, then watch the pipeline catch a below-floor change before it can publish.