Run it in your own cloud, with your data and your keys
OneApp Finance is licensed software you deploy and run as the operator, not a multi-tenant service you log into. Each operator gets a single, isolated instance in their own cloud, with their own database, their own vendor contracts, and their own access controls. The design goal is simple: your loans, your data, and your decisions stay yours, provably.
Single-tenant by design. Not a shared SaaS.
The common loan-origination shortcut is one big multi-tenant database where every operator's loans sit in shared tables, separated only by a tenant ID in application code. OneApp Finance is built the other way: one operator, one instance, one database, deployed where you run it. Physical isolation is the design, not a tier.
Your own cloud, your own instance, your own database
Each operator runs a dedicated OneApp Finance install: deploy it into your own cloud account, or have it run for you as a managed single-tenant install. Either way there is no shared application layer and no shared data plane between operators. Isolation is structural, designed in from the database up, not a row-level filter you have to trust someone never disables.
- One operator per instance. Your program runs on its own instance with its own database. There is no shared multi-tenant table where another operator's loans live next to yours, so a query bug or a missing tenant filter can't leak across operators by construction.
- Deployed where you run it. Run it in your own cloud account under your own controls, or take it as a managed single-tenant install. The deployment model is yours to choose; physical isolation holds either way.
- Many programs, still one tenant. Run home-improvement, solar, medical, or a channel partner as separate programs inside your one instance, each with its own products, rules, and brand skin, all on the database you own.
- Isolation is the floor, not an upgrade. Physical isolation is the design, not a tier. There is no cheaper plan where your data shares a table with someone else's.
What single-tenant means here
- One operator, one instance, one database
- No shared multi-tenant table across operators
- Deploy in your cloud or run as a managed single-tenant install
- Many programs inside the one tenant you own
The data store is yours, and it runs where you run it
Because the instance lives in your cloud, the loan data store is yours: your applications, your borrowers, your decisions, your disclosure artifacts. OneApp Finance is designed so it does not pool your data with anyone else's and does not need a copy of your loan book to operate. Where the data lives is a function of where you deploy, which makes residency something you control rather than something you ask us for.
- Your data store, under your account. The database and document storage sit inside your cloud, under your encryption keys and your retention rules. You hold the operator relationship with the loans and the borrowers; the platform is the engine running over them.
- Residency follows deployment. Run the instance in the region you need and the data is designed to live there. There is no central OneApp Finance datastore your loans flow into.
- No pooling, by design. OneApp Finance does not aggregate your applications, decisions, or borrower data with other operators' for any shared model, benchmark, or marketplace. Your data is not the product.
- Retention is your policy. You and your counsel set retention windows; the platform is built to honor them and to keep the append-only evidence an audit needs within them.
Who holds what
- Your cloud holds the database and the documents
- Residency follows where you deploy the instance
- No central datastore, no pooled operator data
- Retention windows are your policy, enforced in the rails
Your bureau, identity, e-sign, and funding. Your contracts, your keys.
OneApp Finance is built around capabilities, not specific vendors. Every external provider is reached through an adapter you configure, against credentials you own. Nothing critical is hardcoded to a vendor we picked, so swapping a provider is configuration, not a rebuild.
Bureau & identity
Bring your own credit bureau and KYC providers. You hold the contract and the API keys; the platform calls them through a uniform interface. The compliance gates behave the same regardless of which provider sits behind them.
E-sign & disclosures
Your e-sign provider, configured per program or channel. The legally load-bearing disclosure bytes stay OneApp Finance's even inside a partner shell, but the signing rail runs on your account, not a default we chose for you.
Funding & servicing
Your bank, your funding rail, and your servicer are all adapters. OneApp Finance does origination and hands off at boarding through your connection, so money moves on rails you own and control.
Vendors are configured, never hardcoded, so you can change a provider without a platform change. See how the adapters connect →
No god-mode. Separation of duties, wired in.
No god-mode account
There is no single super-user who can quietly do anything to any loan. Access is scoped by program and role, and the platform is designed so the actions that matter most are gated and recorded rather than available to one all-powerful login.
Maker / checker separation
The person who authors a change is designed to be separate from the person who activates it, and high-value funding requires a second distinct approver. There is no path where one operator both proposes and unilaterally executes a sensitive action.
Step-up authentication
Sensitive actions are built to require step-up auth at the moment they happen, not just at login. Per-action re-authentication sits on the non-overridable floor, so a stale session can't quietly move money or sign on a borrower's behalf.
Append-only, hash-chained audit
Every consequential action is designed to write an append-only, hash-chained record. The trail is built so an entry can't be edited or removed after the fact without breaking the chain, which gives an auditor a timeline they can reconstruct years later.
The same controls run the day-to-day console and the safety floor underneath it. See the Operations Portal → · See the override tiers →
Security and compliance are the same floor
Access control and audit aren't a separate product from compliance; they're the same set of invariants the Core is built to re-perform on every action. The rules that should never bend, who verified a borrower, that a disclosure was delivered, that money only moves with proof and balance, are enforced server-side regardless of how the deployment is configured or who renders the screen.
- Enforced in the Core, not on a screen. A kill-switch can stop a capability, but by design it can't disable an invariant. The floor checks run inside the transaction no matter what any config claims.
- Proof, not just policy. Each protected fact gets its own append-only record an auditor can reconstruct, so a control isn't just claimed, it's evidenced.
The same floor, two lenses
- Security: who can act, proven and step-up gated
- Compliance: what must happen, enforced and recorded
- Both: append-only evidence the Core re-performs
- Neither is a toggle an admin can flip off
What this is NOT
It is as useful to say what OneApp Finance deliberately is not, because the deployment and security model follows directly from it.
Multi-tenant SaaS
It is not one shared application and database that every operator logs into. There is no shared data plane, and your loans are designed never to sit in the same tables as another operator's.
A marketplace
OneApp Finance does not run a marketplace of its own or pool applicants across operators. You bring the panel and the channels; the platform provides the rails.
The lender
It is software, not a lender or a broker. You bring the capital and own the credit risk and the borrower relationship; the homeowner never sees our name.
Common questions
Are you SOC 2 certified?
Where does my data live?
Is it multi-tenant?
Can we keep our own vendors and keys?
See the deployment and controls in a live demo
Walk the single-tenant deployment, the vendor-neutral adapters, and the access controls and audit trail, in your own cloud, with your own keys.