virtualbda
All systems protected · Real-time monitoring
All systems protected

Built to be
Unbreachable.

Every layer of Virtual BDA is architected around protection — from the first credential to the deepest deal record. Your data never travels unguarded.

Encryption
256-bit
Perm. Layers
Plain-text
0%
Sec. Score
97/100
Security Score LIVE
97
/ 100
// Core Security Pillars

Three layers. Zero gaps.

Defense begins where the data is born — and never lets go of it.

01 Layer

Encrypted Passwords

Passwords are never stored in plain text. Bcrypt hashing with salted rounds ensures that even if data is ever accessed, passwords remain completely unreadable and irrecoverable.

bcrypt.py
# password never leaves this form
hash = bcrypt.hash("p4$$w0rd", rounds=12)
# stored   → $2b$12$Xy9mPq7R…
# original → irrecoverable
02 Layer

Hashed & Obscured IDs

All entity IDs are cryptographically hashed — impossible to guess, enumerate, or trace back to raw data. No sequential or predictable IDs are ever exposed to the outside world.

hashids.py
# raw ID never exposed
public_id = sha256("deal:4821" + salt)
# → a7f3c9b21e4d8f02…
# sequential guess: impossible
03 Layer

Enterprise Permissions

Three-tier access control — partner, deal, and sub-deal level — ensures every user sees exactly what they're authorized for. Nothing more, nothing less.

Partner Level
organization scope
Deal Level
per-deal gate
Sub-Deal Level
per-person rights
// Enterprise-Grade Permission System

Access control at
every layer.

No one gets in unless they're supposed to. Permissions cascade through three distinct enforcement points — each independent, each absolute.

TIER 01 / PARTNER

Partner-Level Access

Access controls are scoped to the lending partner or institution. Users are bound to their organization — cross-partner data is structurally inaccessible, not just hidden.

TIER 02 / DEAL

Deal-Level Gates

Every deal has its own independent permission gate. Users only see deals they are explicitly authorized for — even within the same organization, unauthorized deals are invisible.

TIER 03 / SUB-DEAL

Per-Person Access Control

Granular control within each deal. Each team member's visibility and editing rights are individually configured — who sees what, who can change what, and to what depth.

Zero-trust by default
Access is denied unless explicitly granted at each tier. No permission inherits by accident — every gate must be opened intentionally.
default → DENY
// Anatomy of a Request

Six gates. One round-trip.

Every request is inspected, authenticated, and scoped before a single byte of data is returned.

Request
inbound
CSRF + CORS
regex origins
JWT Verify
15-min token
RBAC Gates
object-level
ORM Isolation
queryset layer
Encrypted Out
256-bit
// Document Signing

Every signature,
permanently
accounted for.

From envelope to seal, each action is timestamped, attributed, and hash-locked — a complete, tamper-evident trail for every signed document.

Tamper-evident HMAC-verified Immutable hash
Term_Sheet_Meridian.pdf
envelope #DS-4821 · DocuSeal
SEALED
Audit Trail · 5 events
14:02:11
Envelope created
L. Chen · Meridian Capital
14:05:30
Delivered to borrower
magic link · expires 7d
14:06:48
Opened
IP 41.90.x.x · Chrome 126
14:09:22
Signed
webhook · HMAC verified ✓
14:09:23
Sealed — immutable
sha256 a7f3c9b21e4d8f02…
// Security Wins

Engineered, not configured.

Deliberate decisions across every surface of the stack — not a library's defaults.

Authentication

JWT structure
header
·
payload
·
signature
access
15 min
refresh
14 days
Token rotation — blacklisted after every refresh
Magic links — hashed, rate-limited, expiring
Brute force auto-revoke — one wrong guess, done

Authorization

Access matrix
D-4820
D-4821
D-4822
Loan Officer
Borrower
Analyst
Multi-tier RBAC — 7+ permission classes, object-level
ORM isolation — enforced at queryset, before serializers
DocuSeal ACLs — explicit rows, partner-scoped staff

HTTP & API Security

Request path
REQ
CSRF
CORS
HMAC
✓ OK
regex origins 15+ https compare_digest
Custom CSRF — regex origins, referer validated
CORS whitelist — 15+ explicit HTTPS origins, no wildcard
Webhook HMAC — timing-safe compare_digest()

Data Protection

# ID obfuscation
raw deal:4821
↓ SHA-256 + salt
pub a7f3c9b21e4d…
# password validators
similarity min-length blocklist no-numeric
Hashid obfuscation — BigHashidAutoField, enumeration impossible
4-layer passwords — similarity, length, blocklist, no-numeric
Atomic writes — critical mutations in atomic()

Secrets & Infrastructure

.env.production
SECRET_KEY=••••••••••••••••••
AWS_ACCESS_KEY=••••••••••••••
DOCUSEAL_KEY=••••••••••••
HMAC_SALT=••••••••••••••••
HASHID_SALT=••••••••••••••••
Zero hardcoded credentials — every secret in env vars
Activity logging — last-login, latest activity, webhook events
// STANDOUTS

Deliberate, not default.

Decisions that show real security thinking — not library defaults.

auto-revocation timing-safe HMAC object-level RBAC
// Incident Response · Live

The moment it breaks,
we already know.

Every frontend exception is captured, written to the database, and pushed to Slack in real time — so the team responds on the insight, instantly.

EXCEPTION THROWN
TypeError: cannot read
properties of undefined
at DealCard.render()
route /deals/4821 · client
incidents-prod
Virtual BDA MonitorAPP14:32
Frontend exception · TypeError
user #a7f3 · /deals/4821 · Chrome 126
AcknowledgeView in DB
WRITTEN → fe_exceptions
ida7f3c9
typeTypeError
seen_at14:32:08
statusOPEN
TEAM RESPONDS
38s
to acknowledge
JC RM +3
on-call · online
100% of FE exceptions captured Slack + DB in parallel Full stack trace + user context