Security & Compliance

Enterprise-Grade Security. Full Regulatory Compliance.

Alberta Verified Financial Exchange (AVFE) is built for institutions that cannot afford ambiguity: FINTRAC money services business (MSB) registration, CRA-aligned receipt and charity verification workflows, cryptographic protection of data at rest and in transit, and an append-only audit architecture that detects tampering—not marketing slogans, but operational controls reviewed under Canadian law. We run on our own infrastructure in Canada; public hyperscale clouds (AWS, GCP, and Azure) are excluded on principle, so your sensitive flows never depend on foreign jurisdictions or opaque shared tenancy.

Regulatory

Canadian oversight, documented and maintained

AVFE aligns product decisions with federal expectations for anti–money laundering, terrorist financing, sanctions, and charitable integrity. The sections below summarize how we situate ourselves relative to key regulators—not legal advice for your organization, but a transparent statement of our posture.

FINTRAC MSB registration

AVFE operates as a Money Services Business under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act (PCMLTFA). That means policies, training, record retention, and reporting channels are designed for FINTRAC examination—not retrofitted after launch. We file suspicious transaction reports (STRs), large cash transaction reports (LCTs), and electronic funds transfer reports (EFTRs) when thresholds and typologies require, and we maintain a designated compliance workflow so nothing material slips between engineering and governance.

CRA compliance

Official donation receipts and supporting data fields are structured to meet Canada Revenue Agency expectations for registered charities: consistent numbering, required disclosures, and traceability from issuance through correction. Masjid partners remain responsible for their own filings; AVFE supplies controls and exports that make year-end review and auditor requests less painful. Charity verification during onboarding is treated as an ongoing obligation, not a one-time checkbox.

OSFI sanctions screening

We run daily automated sanctions and watch-list screening aligned with Office of the Superintendent of Financial Institutions (OSFI) guidance, complementing event-driven checks at onboarding and material profile changes. Hits route to a controlled review queue; outcomes are logged for audit. Screening is one layer in a broader risk program—velocity monitoring, typology alerts, and human judgment still matter—but the cadence is non-negotiable.

Data protection

Encryption everywhere secrets matter

Sensitive data at rest is protected with bank-grade encryption across databases and durable stores. Traffic between donors, masjid administrators, and AVFE APIs uses encrypted connections on the edge and inside our perimeter where components authenticate to one another. Application secrets, API keys, and integration credentials never live in source control: they are injected from our encrypted vault, with strict rotation and least-privilege policies so a compromised build artifact cannot become a skeleton key.

At-rest encryption designed for key management discipline, not checkbox compliance
Modern encrypted transport; legacy protocols disabled at the boundary
Centralized secrets lifecycle—no “shared .env” culture for production

Immutable audit trail

Append-only events you can defend in review

Our audit store is INSERT-only: ordinary application roles cannot UPDATE or DELETE historical rows. Each record includes a cryptographic hash that incorporates the prior row’s hash, forming a hash chain across the sequence. Altering an old entry breaks the chain—supporting tamper detection and structured disclosure to auditors when appropriate. This is not a public blockchain; it is a private, integrity-first ledger for regulated operations.

Backups and disaster recovery rely on real-time disaster recovery replication to geographically separated Canadian-hosted capacity, so continuity plans do not depend on a third-party cloud region.

No retroactive edits to material compliance events
Chain verification can be replayed for forensic or audit exercises
Replication provides RPO/RTO targets without outsourcing disks to hyperscalers

Verification process

Know your partners, know your donors—proportionately

Verification is layered: masjids pass a structured onboarding program; donors encounter KYC thresholds that scale with exposure; integrations prove authenticity before we mutate balances.

Masjid 5-gate verification

Before a masjid receives live payouts, AVFE completes five gates: CRA registry and governing documents, banking legitimacy including micro-deposit confirmation, leadership and profile review against stated charitable purpose, operational readiness checks, and a recorded onboarding call so expectations are mutual. Gates can be re-opened if risk signals or documentation drift.

Donor KYC tiers

Donor due diligence is risk-based. Cumulative giving under $1,000 can remain lightweight (no full identity program). Between $1,000 and $3,000, we collect basic KYC suitable for FINTRAC expectations at elevated exposure. Above $3,000, donors provide government-issued identification and supporting checks before additional capacity unlocks. Thresholds apply to rolling windows defined in policy and are subject to escalation for anomalies.

Webhook security

Bank and partner webhooks are accepted only with cryptographic signature verification using rotated secrets from our encrypted vault. Processing is idempotent: duplicate delivery with the same logical key cannot double-credit a masjid. Integrations must acknowledge within five seconds; long work is queued internally so endpoints stay reliable under load.

User privacy

Donor dignity is a control, not an afterthought

AVFE does not operate a public feed or ledger of transactions. Your giving history is visible only within authenticated surfaces governed by policy—never browseable like social activity. Masjid administrators see what they need for receipts and reconciliation; they do not receive a marketing-style stream of other donors’ behaviour.

Role-based access control maps every session to one of: donor, masjid_admin, avfe_admin, or compliance_officer. Each role carries scoped permissions; elevation requires break-glass procedures and logging. Authentication uses JSON Web Tokens: short-lived 15-minute access tokens paired with 30-day refresh tokens, rotation on use, and server-side invalidation paths for compromise response.

Privacy and security engineering work together: minimizing data display, encrypting payloads, and ensuring compliance staff can fulfill FINTRAC duties without turning the platform into a surveillance showcase.

At a glance

RBAC donor · masjid_admin · avfe_admin · compliance_officer
JWT 15-minute access token · 30-day refresh · rotation-aware APIs
Private No public transaction feed; disclosure is purposeful and logged

Trust indicators

What “verified” means on our perimeter

These labels describe live engineering and governance commitments—not stickers we bought from a vendor marketplace.

FINTRAC Registered

CRA Verified

Bank-Grade Encrypted

Canadian-Hosted Infrastructure

OSFI Screened

Immutable Audit

FAQ

Security & compliance questions

Direct answers about regulation, data location, verification, and how we respond when something looks wrong.

Yes. Alberta Verified Financial Exchange is registered as a money services business (MSB) with the Financial Transactions and Reports Analysis Centre of Canada (FINTRAC). That registration frames our obligations under the PCMLTFA, including know-your-client measures, record keeping, and reporting such as STRs, LCTs, and EFTRs when applicable. Regulation is an operating reality for us—not optional branding.

Primary systems run on infrastructure we operate in Canada. We deliberately avoid public hyperscale clouds—AWS, Google Cloud, and Azure are not part of our core stack—because sovereignty, predictable tenancy, and architectural discipline matter for the communities we serve. Disaster recovery uses real-time disaster recovery replication to separate Canadian-hosted capacity, not a foreign region owned by a U.S. hyperscaler.

Payment partners send signed webhooks; we verify each payload with cryptographic signature verification before changing balances or receipt state. Handlers are idempotent so network retries cannot duplicate credits. That cryptographic handshake is how we know an event genuinely originated from the integration we configured—not from a replayed HTTP call on the open internet.

Suspicious behaviour escalates to our compliance officer workflow. Where the facts meet FINTRAC thresholds, we file a suspicious transaction report (STR) and preserve records in the immutable audit trail. Masjid partners may receive limited notices when we must freeze or delay settlement for legal reasons; we do not discuss open cases publicly.

We do not publish a public ledger or social-style feed of donations. Masjids see information required for receipts and reconciliation under their masjid_admin roles; donors see their own history under donor accounts. compliance_officer and avfe_admin access is tightly scoped, logged, and justified by policy. Where law or regulation compels disclosure to authorities, we comply—otherwise we treat personal data as confidential.

The audit database is INSERT-only: routine application roles cannot run UPDATE or DELETE against historical rows. Each entry links to the previous through a hash chain, so tampering with an early record breaks verification. Combined with bank-grade encryption at rest, encrypted connections in transit, and replicated database standbys, the trail is both confidential and resilient.