Architecture
Built like a system, not a tool
Structured architecture, controlled data flow, and enforced workflow — designed so that reliability and consistency hold as the number of tenants, partners, and files grows.
Core architecture
Multi-tenant with controlled access
Each partner, organization, and borrower operates within a controlled environment. Data is isolated, permissions are enforced at the system level, and access is governed by role rather than by request.
- Tenant isolation prevents data crossover between organizations
- Each user operates within a defined scope
- Permissions are enforced at the system level, not the interface
- Visibility is controlled by role, not preference
FCH global administration
Owns the rulesSystem-level authority. Underwriting logic, engine configuration, and platform governance live here and are not editable downstream.
White-label tenant
Owns its environmentBranding, domain, internal teams, its own clients, and billing within assigned permissions. Cannot see other tenants or alter central underwriting logic.
Certified Partner
Owns its bookIts own clients, pipeline, readiness, documents, and conditions within permission scope. Cannot override underwriting or skip gates.
Borrower / client
Owns its fileIts own state, documents, tier progression, and next required action. Cannot trigger data pulls, select capital sources, or bypass sequencing.
Visibility flows downward and never sideways. A tenant cannot see another tenant, a partner cannot see outside its book, and a borrower sees only its own file. Access is defined by role — not by preference or request.
Access control
Four scopes, each deliberately bounded
Every user action is governed by role-based permissions. The interesting part of an access model is not what each role can do — it is what each role cannot reach.
FCH global administration
01 · System-level authorityOwns underwriting logic, engine configuration, and platform governance. This scope is not delegated downstream, which is what makes outcomes consistent across every tenant.
White-label tenant owner
02 · Tenant-level authorityControls branding, domain, internal teams, client ownership, and billing visibility within assigned permissions — inside their environment and no further.
Certified Partner
03 · Book-level authorityManages their own clients, pipeline, readiness, documents, and conditions within permission scope. Cannot reach outside their book or override the rules.
Borrower / client
04 · File-level visibilitySees their own state, documents, progression, and next required action. Cannot trigger data pulls, select capital sources, skip gates, or view internal logic.
Least privilege is the design goal: a new capability inherits the narrowest scope that makes it work, and widening it is an explicit decision rather than a default.
Data and workflow governance
Data is not accessed on demand. It is accessed with intent.
Six architectural controls that govern how information moves through the platform and what has to be true before a file can advance.
Tenant-scoped data isolation
Every record carries tenant scope. Queries are constrained at the data layer rather than filtered at the interface, so isolation does not depend on a screen behaving correctly.
Role-based access control
Access to data, workflows, documents, and functions is defined by role. New capabilities inherit the narrower scope by default rather than the broader one.
Controlled data middleware
Third-party and bureau data is reached only through approved system workflows. There is no user-facing path that triggers an external call on demand.
Refresh cycles and cost protection
Data refresh is governed by defined cycles rather than user behavior, so external data cost tracks operational need instead of curiosity.
Centralized document handling
Documents live in one vault with categorization and verification status. Requirement logic determines the needed set by file type rather than by habit.
Audit-aware state history
Stage transitions, condition changes, and workflow events are recorded as history. A file's path can be reconstructed after the fact, including who acted and when.
Why it was built this way
Infrastructure first, interface second
Most platforms in this category were built as tools layered on top of a service business. When the underlying model is a service, software can assist the process but cannot govern it.
Building the data layer, the tenant model, and the control layer first is slower to start and considerably harder to retrofit. It is also the only order that produces a system where a rule written once applies everywhere, to everyone, without depending on anyone remembering it.
The goal is not to assist the process. The goal is to govern it.
Operational discipline
The platform is designed to maintain data integrity, enforce process consistency, and reduce risk across user interactions through the controls described on this page.
On certifications and security claims
This page describes architectural design and operational practice. It does not assert SOC 2, PCI, or HIPAA compliance, specific encryption standards, penetration-test results, uptime SLAs, or regulatory certification. Where a formal attestation is required for your evaluation, request it directly and it will be addressed on its own terms rather than implied here.
Financing is subject to underwriting and program eligibility. Platform outputs support readiness evaluation and workflow; they are not guarantees of approval.
Next step
See the architecture in action
The walkthrough covers tenant isolation, role scoping, the control layer, and how workflow gating behaves in practice — with the interface in front of you rather than described.
Financing is subject to underwriting and program eligibility. Platform outputs support readiness evaluation and workflow; they are not guarantees of approval.