Compliance built into the rails, not bolted on after
Most loan-origination systems treat compliance as a screen of toggles someone can flip off. OneApp Finance inverts that. The rules that should never bend are designed to be enforced server-side by the Core, every time, no matter how the deployment is configured or who renders the screen.
Not a lender. Software.
OneApp Finance is origination software. We don't lend money, we don't hold the loan, and we don't give legal advice. You and your counsel set the policy: which products run in which states, your adverse-action language, your rate caps, your retention rules. OneApp Finance enforces it on every loan, proves it happened, and refuses to act when a required input is missing. Think of it as the floor under your compliance program, not a replacement for it.
Three counts that don't move
Real, frozen numbers, not metrics we invented. Each one is a design commitment baked into the rule set.
Frozen invariants: safety rules the Core is built to enforce regardless of how any operator configures their deployment. They live in one source-of-truth registry, and a test asserts the count stays exactly 16: the floor beneath all policy.
Disclosure proofs. Every disclosure document is designed to write four separate, append-only records: generated, delivered, accessed, signed. A signed agreement doesn't prove it was delivered, so each fact gets its own proof an auditor can reconstruct years later.
State matrix, fails closed. Your counsel fills in a per-product, per-state, per-channel legality matrix. No product goes live in a state without an approved classification row. Empty means off: the system refuses rather than guesses.
Rules nobody can toggle off
The common failure in this category is a rule that should have been non-negotiable being left as a flag someone could flip, a check someone could skip, or a gate that silently passed when a vendor was down. OneApp Finance's answer is a frozen set of platform safety rules the Core is built to re-perform on every action. A kill-switch can stop a capability, but by design it can never disable an invariant.
- No loan acts without a verified borrower. Nothing activates, signs, or funds without a contact the borrower controls, proven on the borrower's own device. If a contractor tries to swap in their own contact, the system flags it and forces an exception review.
- No money moves without proof and balance. No disbursement without an idempotency key, a funding-approval event, authorization evidence, and a balanced double-entry ledger. An unbalanced write aborts the whole transaction.
- No decline without the Reg-B clock. An application can't reach a final declined state without an adverse-action tracker and a notice path bound to the legally-correct issuer of record.
- No disclosure without provenance and delivery. No disclosure package without product, version, state, channel, and template IDs plus E-SIGN consent, and the fact that delivery occurred sits on the non-overridable floor.
How it holds
- Each invariant names the exact layer designed to enforce it (database constraints for data integrity, application guards for business rules), so it's defended in depth, not in one place.
- The set is fully specified: every invariant carries a precondition, a named enforcement layer, and a written adversarial test. The rule set is frozen as the floor every future feature is built above.
Version-pinned, with four separate proofs
The most legally load-bearing surface in the product. Every disclosure is designed to run an ordered sub-machine (consent, generate, deliver, access, sign), and any out-of-order step is rejected. The TILA figures are computed from the frozen offer the borrower selected, never re-derived from live config that may have drifted since.
- Generated. The exact bytes, pinned to a counsel-approved template version with the product, program, state, and channel recorded, plus a PDF hash. The TILA disclosure and the contract are separate pinned documents.
- Delivered. Sent to the verified contact. Delivery is its own fact with its own proof, and it sits on the floor that no one can override.
- Accessed. The borrower opened it. Recorded separately so an auditor can reconstruct the timeline: generated at T1, delivered at T2, accessed at T3, signed at T4.
- Signed. The borrower executed it. Signing freezes a final-terms snapshot, computes a terms hash, and moves the signed package to write-once storage. Funding then requires the funded terms to match the signed terms exactly.
What that prevents
- The disclosure bytes are OneApp Finance's, even inside a partner's branded shell. The "trust the partner's submitted hash" shortcut is structurally unavailable for any legal document.
- A material change, such as a worse go-to APR after a promo, a longer term, a re-allocated dealer fee, or a different payee, voids the signed envelope and forces re-disclosure before any money moves, even if the dollar amount is identical.
KYC, OFAC, and AML are three distinct gates
Identity, sanctions, and watchlist screening are modeled separately so the three are never conflated, each with its own evidence and its own consequence.
KYC / CIP: is this the real borrower?
Identity verification runs on the borrower's own device. Holding the phone isn't enough. The line has to bind to the named applicant. A burner the salesperson controls returns "no match" and is forced into document ID verification. This is the structural answer to a contractor completing a homeowner's financing for them.
OFAC: are we legally allowed to transact?
OFAC is always re-performed by the Core, even when the identity screen was delegated to a partner. The result is stored as a write-once artifact pinned to the exact sanctions-list snapshot date, and re-screened again at funding time because lists update daily. A block is a legal prohibition, never a creditworthiness decline, and no borrower notice ever says "sanctions match."
AML / BSA: a separate watchlist gate
AML and BSA screening is modeled as its own gate, distinct from identity and from OFAC, so the three are never conflated. A hit routes to compliance review, not to an adverse-action decline.
Ops can always move a file forward. The floor never bends.
Legal floor: never overridable
OFAC, the runtime military-rate cap, AML/BSA, rescission and cooling-off holds, per-action re-authentication, and the "disclosure was delivered" fact. The only thing that satisfies these is the real automated artifact. No attestation, no exception.
Business floor: overridable with evidence
Operational gates can be advanced by a named role with a typed reason and proof, logged immutably. For high-value funding, a second distinct person must approve. There is no "skipped" state, only "satisfied by a human-attested artifact."
Borrower-payout consent: protected by default
The homeowner's sign-off before a contractor is paid is non-overridable by default. A device-absent path can only be enabled with out-of-band proof, maker-not-checker, and an attester outside the dealer's reporting chain. Tighten it, never loosen it.
Freely configurable: your policy
Cooling-off day counts, principal-reason caps, grace windows, which roles may attest which gates. Operator policy, version-pinned and audited.
Common questions
Does OneApp Finance give legal or compliance advice?
Can our admin just turn a compliance check off?
What happens if a state isn't configured yet?
Can we keep our own bureau, KYC, or e-sign vendor?
How the floor is set, deployed, and run
Config Studio
Where you author policy above the floor: every knob resolves to a tier, and below-floor drafts are rejected server-side at publish.
Explore →Security
The single-tenant, your-cloud deployment the rules are enforced inside: physical isolation by design, controls you own end to end.
Explore →Operations Portal
The override tiers in daily practice: typed reasons, proof, step-up auth, and an append-only record for every act past a gate.
Explore →See compliance enforced, not just configured
Walk through the 16 invariants, the four disclosure proofs, and the override tiers in a live demo.