Skip to main content
Security Architecture

Security that protects what matters most

We built YBAWS! to handle the most sensitive financial and personal data in Canada, estate documents, financing records, and net worth statements. Security isn't a feature. It's the foundation.

Zero-Knowledge
AES-256-GCM
Shamir's SSS
3-of-5 threshold
Blockchain
Polygon audit trail
Canada Only
Toronto data centre

Zero-Knowledge Encryption

AES-256-GCM

We cannot read your clients' data. Ever. The encryption key is derived from information only you and your client hold, it never touches our servers in a form we can use.

Technical Implementation
  • All document data is encrypted client-side using AES-256-GCM before transmission.
  • The data encryption key (DEK) is itself encrypted with a key derived from the user's passphrase and a server-side HKDF expansion, never stored in recoverable plaintext.
  • Each vault record uses a unique DEK. Key rotation is supported without re-uploading documents.
  • Metadata fields (file names, dates) that must be queryable are encrypted with deterministic AES-256-SIV to preserve searchability without exposing content.
  • TLS 1.3 with forward secrecy protects all data in transit.

Shamir's Secret Sharing (5-of-3)

Shamir's Secret Sharing

A deceased client's vault cannot be opened by one person acting alone. The vault key is split into 5 cryptographic shares held by different parties. Any 3 are required to reconstruct the key. No single executor, no single employee, and not even YBAWS! can open a vault unilaterally.

Technical Implementation
  • Vault master keys are split using Shamir's Secret Sharing with a 5-share, 3-threshold scheme (3-of-5).
  • Shares are distributed: one to the estate executor, one to the designated CPA, one to an independent legal contact, and two held in escrow by YBAWS! in geographically separated vaults.
  • The share reconstruction ceremony requires multi-party authentication, each share holder authenticates via TOTP + email OTP before their share is committed to the reconstruction.
  • Share refresh (proactive secret sharing) is performed annually without invalidating vault contents.
  • The full reconstruction is logged on the Polygon blockchain before any vault content is decrypted.

Blockchain Audit Trail

Polygon

Every vault access event, who opened it, when, and which shares were used, is permanently recorded on the Polygon blockchain. No one can alter or delete this record. If something looks wrong, there's a 72-hour window to dispute the access before any data is released.

Technical Implementation
  • Vault access events are hashed (SHA-256) and written to the Polygon PoS blockchain within seconds of occurrence.
  • The on-chain record includes: vault ID (hashed), initiating party identity hash, timestamp, share contributor identifiers, and a merkle root of the accessed document manifest.
  • A 72-hour cryptographic time-lock is enforced between the logged access event and any actual decryption release. During this window, any of the 5 share holders can submit a dispute transaction that freezes the vault.
  • Dispute transactions require a 2-of-5 share holder counter-signature to lift the freeze.
  • Audit logs are also mirrored to immutable object storage (WORM policy) in Canada as a secondary non-repudiation layer.
  • All on-chain interactions use gas-optimized contracts audited by a third-party security firm.

PIPEDA Compliance

PIPEDA

PIPEDA, Canada's federal private sector privacy law, governs how personal information is collected, used, and disclosed. YBAWS! is designed from the ground up to be PIPEDA-compliant. Not retrofitted. Not checked at the end. Designed that way.

Technical Implementation
  • Explicit informed consent is collected at each stage of data collection, separate from the engagement agreement.
  • Clients can request a full data export or deletion at any time via the client portal.
  • Data minimization is enforced at the schema level: fields that aren't needed for a given engagement type cannot be populated.
  • The CPA firm acts as the "organization" under PIPEDA; YBAWS! acts as a data processor under contract.
  • Our Privacy Officer can be reached at privacy@ybaws.ca for PIPEDA inquiries.
  • Breach notification procedures comply with the mandatory 72-hour reporting requirement under PIPEDA's breach of security safeguards regulations.

Canadian Data Residency

Toronto, Canada

Your clients' data never leaves Canada. Full stop. Our infrastructure runs in Toronto on Canadian servers. No cross-border data transfers. No US-accessible storage. No ambiguous "global CDN" clauses.

Technical Implementation
  • All production infrastructure is hosted in AWS ca-central-1 (Toronto).
  • Supabase Postgres and Storage instances are pinned to ca-central-1 with no automatic failover to non-Canadian regions.
  • No US-based third-party services process Canadian client PII. All AI inference (Claude API) is routed through a Canadian API proxy that strips PII before processing.
  • Email delivery (transactional) routes through a Canadian SMTP provider.
  • Disaster recovery uses a secondary site in ca-west-1 (Calgary), still within Canada.
  • Data Processing Agreements (DPAs) are available for CPA firms that require them for their own compliance programs.

72-Hour Dispute Window

72-hour window

Before any vault is opened and its contents released to a beneficiary or executor, there's a mandatory 72-hour waiting period. This gives family members, co-executors, or legal counsel time to flag an issue before anything is released.

Technical Implementation
  • The 72-hour countdown begins when the vault access event is written to the blockchain.
  • All registered share holders and designated contacts receive an immediate email and SMS notification when a vault access is initiated.
  • Any share holder can submit a dispute transaction on-chain during the 72-hour window. The dispute immediately freezes the release countdown.
  • A frozen vault requires a formal dispute resolution process: either a 2-of-5 share holder vote to release, or a court order uploaded and verified by YBAWS! compliance staff.
  • Dispute events are themselves logged on-chain, creating an auditable chain of custody.

Role-Based Access Control

Role-Based Access

Not everyone at your firm can see everything. Access is tightly scoped: a junior accountant working on a tax return cannot see the estate vault. A client can only see their own data. An admin cannot access another firm's data.

Technical Implementation
  • Multi-tenant isolation is enforced at the database level using row-level security (RLS) policies on every table via tenant_id.
  • Roles: super_admin (YBAWS! staff), cpa_admin (firm owner), cpa_staff (firm employee), client, lender.
  • Permissions are additive and role-scoped. RLS policies check both tenant_id and role before returning any row.
  • Vault access requires an explicit grant from the client in addition to role authorization. A CPA cannot access a client's vault unless the client has named them as a share holder.
  • All admin actions (role changes, share holder assignments) emit an audit event stored in a separate append-only audit log table.
  • Session tokens expire after 8 hours of inactivity. Refresh tokens are rotated on each use.

Infrastructure Security

Infrastructure

We use modern cloud security practices across the stack: encrypted at rest, encrypted in transit, private networking, and regular third-party penetration testing.

Technical Implementation
  • All data at rest is encrypted with AES-256 using AWS KMS-managed keys with annual rotation.
  • RDS and S3 storage use server-side encryption (SSE-KMS) in addition to application-layer encryption.
  • All internal service communication occurs over private VPC networking, nothing is exposed to the public internet without an explicit gateway.
  • Web application firewall (WAF) with OWASP Top 10 rules + rate limiting on all public endpoints.
  • Automated dependency vulnerability scanning on every commit via Dependabot + Snyk.
  • Annual third-party penetration testing by a Canadian security firm. Summary reports available on request for enterprise customers.
  • SOC 2 Type II audit in progress. Expected completion Q3 2026.

Responsible Disclosure

If you discover a security vulnerability in YBAWS!, please report it to security@ybaws.ca. We respond to all reports within 24 hours and will work with you to resolve the issue responsibly. We do not pursue legal action against researchers who report in good faith.

Questions about our security architecture?

We're happy to walk through the technical details with you, your IT team, or your compliance officer.