crerail.ai
For your IT team.
The controls behind the plain-English summary — identity, authorization, data classification, retention, transport and build-time enforcement. Written for whoever runs your vendor review.
Identity and authorization
Per-role principals
Every participant type authenticates to a distinct principal carrying its own custom claim — broker, lender, attorney, investor, vendor and agency staff. A counterparty principal is not a reduced-privilege staff principal; it is a separate identity class evaluated by separate rules.
Deny-by-default datastore rules
Counterparty principals deliberately carry no approval claim, so they satisfy no read rule on transaction collections. There is no permissive rule for a bug in the application layer to fall through to.
Projection-only reads
Client reads of transaction data go through server-side callables that return a fixed field whitelist, never a document reference. Broadening a role's visibility is a reviewed code change to that whitelist. Test suites feed the projections a fully-populated record and assert that excluded fields are absent from the output.
Mediated writes
Client applications do not write to the datastore. Every mutation is a callable that re-verifies the caller's access to the target record server-side before it executes, under the Admin SDK.
Isolation
Separate bundles and origins
Each portal is an independently built and independently hosted application. Staff-only interfaces are not code-split or feature-flagged away from counterparty portals — they are not present in the deployed artifact.
Tenant resolution per caller
Organisation identity, branding and data scope resolve server-side from the caller's own claim. There is no default tenant in client code. An unresolved session renders platform-neutral chrome with no logo, which is a deliberate fail-closed rather than a fallback to a default org.
Side scoping within a transaction
Document visibility is an enumerated level — staff-only, buyer's side, seller's side, counsel, an explicit list, or all parties. An unrecognised value decodes to staff-only: the default is invisible, not visible.
Continuous enforcement
Isolation invariants are asserted by a build-time guard that fails the pipeline in both directions — a new violation fails, and a stale exemption for something since fixed also fails, so the exemption list can only shrink.
Sensitive data
Classification drives scope
Records describing land — surveys, environmental reports, recorded instruments — are separable from records describing people or money. Identity documents, bank details, settlement figures and closing instructions are bound to their originating transaction and are never propagated beyond it.
Non-public personal information
Party contact records deny client reads outright. Identity-verification and bank-verification collections are deny-all, are absent from every counterparty bundle, and are not reachable by any client read path.
Reveal controls
Server-side reveal of decrypted values requires the staff claim plus a fresh second-factor step-up, is additionally gated by a build-time flag that is off unless explicitly set, and writes an audit record on every attempt.
Retention
Sensitive classes carry defined maximum retention with scheduled deletion, documented in the Data Retention and Deletion Policy, available on request under NDA.
Authentication
Multi-factor
Time-based one-time-password (TOTP) second factors are supported on every surface — the agency portal and all five counterparty portals — and can be required by organisation policy. Recovery does not disclose whether an address is registered.
Client attestation
Application-attestation is integrated on every client, with a build guard that fails the build when the site key is absent, so an unattested client cannot ship by omission.
Invitation-based provisioning
Counterparty accounts are created by an agency action against a named person on a specific matter. There is no open registration into any counterparty portal, and no self-service path to a transaction.
Transport and delivery
Response headers
Strict Content-Security-Policy with an explicit source allowlist; HSTS with includeSubDomains and preload; X-Content-Type-Options nosniff; Referrer-Policy no-referrer; frame-ancestors none; and Permissions-Policy disabling camera, microphone and geolocation.
Payment instructions
Banking instructions are delivered through single-use verified links, not as email attachments, and are never mailed in changed form. Recipients see exactly one account and a call-to-verify instruction.
Aggregate data
Minimum-count suppression
A benchmark cell is published only when computed over at least five underlying transactions. Pooled cross-agency figures additionally require at least five contributing organisations. Suppressed cells are rendered absent, never as zero, and every dimensional slice passes the same test independently.
Contribution is consent-based
Participation in pooled benchmarks is a recorded, timestamped election by the organisation, not a default.
Available under NDA
Data Retention and Deletion Policy · Incident Response Plan · Information Security Risk Assessment · penetration and audit summaries · a completed security questionnaire in your own format. Ask and we will send them.
This page describes architecture and controls. It is not a substitute for a signed agreement, and specific commitments — uptime, breach notification timelines, subprocessor lists, audit rights — belong in that agreement rather than on a web page.