Security, in depth.

Members sign in once at tier one. Reaching a lender or admin workspace requires a tier-two step-up — a uniform posture with no per-lender opt-out.

Privileged actions take a second factor — TOTP on web, Face ID on mobile — gated through a dedicated elevation flow.

Elevated sessions step back down on their own after roughly 30 minutes idle, with stricter cookie scoping for tier-two.

Sessions can be revoked centrally so a compromised or lost device can be cut off without waiting for it to expire.

New and changed passwords are checked against known-breached corpora (HIBP, k-anonymity range query — the password never leaves the server in clear).

Login and recovery responses are shaped so an attacker can't probe which accounts exist; failed attempts are rate-limited and logged.

Sensitive fields are sealed with authenticated AES-256-GCM — so a copy of the database, on its own, reveals nothing.

Encryption keys are versioned and rotatable; ciphertext carries its key version so rotation never strands old records.

Every access to personal data is logged; emergency break-glass access is recorded distinctly; retention windows auto-purge data that has aged out.

Each lender's data is partitioned so one institution can never read another's. Postgres row-level security policies are applied and enforced through a dedicated application role — isolation at the database layer, not just the application.

Each entry chains to the one before it; altering any record breaks the chain visibly. The trail is append-only, not editable in place.

The chain is replicated to write-once, read-many storage off the primary box, so a single compromised host can't erase history.

Security events and AKAD signings are recorded with their cryptographic context, giving lawful processes a defensible, verifiable record.

Periodic anchoring of the chain root to an independent external timestamp — for third-party-verifiable integrity — is being added.

Apps ship compiled to Hermes bytecode rather than readable JavaScript, raising the bar on reverse engineering.

Tokens and keys live in the OS secure store (expo-secure-store), never hard-coded into the app bundle.

Sensitive surfaces and role elevation can be gated behind Face ID / fingerprint on the device.

Production builds will pin the API certificate so traffic can't be silently intercepted. Wired behind a provider registry; being armed in production builds (not in Expo Go / preview).

Production builds will detect compromised devices and tampering, wipe our secrets, and fail safe. Pluggable RASP provider, being armed in the production build.

Device and app attestation to confirm requests come from a genuine, untampered app — keys being provisioned and enabled in production builds.

A web application firewall with deny rules plus invisible bot protection (BotID) guards high-value routes such as login, sign-up, and chat.

Per-route rate limits throttle abuse; repeated failed authentication triggers automatic account lockout.

HSTS with preload, X-Frame-Options DENY, X-Content-Type-Options nosniff, a strict Referrer-Policy, COOP/CORP, and a restrictive Permissions-Policy ship on every response.

Unusual patterns raise alerts and can trigger defensive responses, with the events captured on the tamper-evident trail.

frame-ancestors is already enforced. The full nonce-based Content-Security-Policy and CSRF protection run in Report-Only today, collecting violations as we move them toward full enforcement.

Request payloads are validated with typed schemas (zod) at the boundary, so malformed or hostile input is rejected before it reaches business logic.

Inbound webhooks are verified by signature and protected against replay, so a captured payload can't be re-sent to forge an event.

Dependencies are monitored for known vulnerabilities and the codebase is scanned to keep credentials out of the bundle and out of source.

Every change goes through a recurring code-level security review. (Independent third-party penetration testing is planned, not yet performed.)

Security and operational controls are designed against Bank Negara Malaysia's expectations for regulated lending technology.

Personal data is collected on consent, access-logged, and retention-bounded — handled in line with the Personal Data Protection Act.

Islamic financing flows are designed to settle over Shariah-compliant Tawarruq trading rails. The integration is built and UAT-complete with a licensed commodity-trading partner; at go-live, the resulting e-certificates stitch into the audit trail.

If we're attacked, we preserve our tamper-evident evidence and hand it to the proper authorities — MyCERT, the police, and lawyers do the lawful tracing. We explicitly do not retaliate, counter-hack, or de-anonymise; that would itself be unlawful.

Postgres row-level security policies bind every tenant query, so the database itself refuses to return another institution's rows — isolation enforced below the application, not just within it.

AI processing runs in Malaysia, under service terms that prohibit storing prompts and outputs and prohibit using them to train models — no-storage, no-training, by contract.

Every consequential action is hash-chained into an append-only trail, so the record can't be quietly rewritten. External anchoring of the chain root — for third-party-verifiable integrity — is rolling out.

Data is retained only as long as servicing and Malaysian law require, under a published retention policy, with automated deletion sweeps purging what has aged out.

Our staged enterprise tier: raw data stays in your perimeter; only anonymized, audit-grade intelligence leaves. Talk to us about the rollout.