Security, Zero-Retention, and Data Protection.

🔒 Zero Data Retention

MapleSchema operates as a stateless transformation layer. Open banking transaction payloads are processed in memory and discarded immediately after a response is generated.

• No databases for transaction data.
• No object storage buckets for payloads.
• No write permissions for storing raw or normalized transactions.

If an attacker gained access to our servers, there would be no historical transaction data for them to exfiltrate.

🇨🇦 Canadian Hosting

MapleSchema is hosted on Canadian infrastructure. Transaction payloads are processed within Canada and are not forwarded to third countries as part of the normalization process.

This design aligns with the expectation that Canadian open banking data remains under Canadian jurisdiction and helps support regional compliance requirements.

🧱 Minimal Attack Surface

MapleSchema is intentionally small and focused: a single-purpose API that normalizes transaction payloads. There are no dashboards, user-uploaded files, or complex multi-user UX flows that expand the attack surface.

• No persistence layer for transaction data.
• No embedded third-party scripts in the transformation path.
• Strict IAM so services only have the permissions they need.

🔑 API Security

Access to the MapleSchema API is controlled through API keys and Project IDsissued to each project.

• All requests must use https:// — plain HTTP is not supported.
• Requests require a valid API key sent via header.
• Requests are rate-limited to reduce abuse and brute-force attempts.
• Payload sizes are limited to protect service stability.

Invalid or missing authentication results in clear, deterministic error responses so your systems can react predictably.

🪵 Log Hygiene

Logs are critical for operations, but they are also a common source of accidental data leakage. MapleSchema is designed to log only what is needed to operate the service.

• No transaction payload bodies are logged.
• No raw descriptions, account numbers, or card details are logged.
• Logs include high-level request metadata such as timestamp, institution code, and number of transactions processed.
• Logs are protected and periodically rotated.

The goal is to provide enough visibility for reliability and debugging, without exposing sensitive financial data in logs.

🛡️ Transport & Isolation

All API access is encrypted in transit using TLS. Only the public HTTPS endpoints are exposed; internal components are not directly reachable from the public internet.

Production and non-production environments are separated, and configuration is managed via environment variables rather than hard-coded secrets.

🏗️ Stateless Transformation Architecture

The core of MapleSchema is a stateless transformation service. Your systems send open banking transaction payloads, MapleSchema normalizes them into a stable JSON schema, and the results are immediately returned to you.

Once the response is sent:

• No transaction data is stored in a database.
• No transaction data is written to disk.
• No transaction data is queued for later batch processing.

This design keeps the service simple to reason about and significantly reduces the risk surface compared to traditional data-processing platforms.

📚 Compliance-First Design

MapleSchema is not a data warehouse or analytics platform. It is an opinionated, normalization-first API built to minimize your regulatory burden.

• You retain control of storage, access, and retention policies for normalized data.
• We provide a stable, deterministic schema for downstream systems and auditors.
• Our zero-retention posture is easy to explain to security and compliance teams.

As Canadian open banking standards mature, MapleSchema will track changes in field definitions and institution behavior, while keeping the normalization contract predictable.

🔍 Transparency & Versioning

Changes to the normalization schema and adapters are versioned and documented. When MapleSchema introduces new fields or behavior changes, they are done through explicit version bumps (for example, transactions-v1.0 to a future version) rather than silent changes.

This approach helps you:

• Understand exactly how data is being transformed.
• Review changes with your own legal, risk, and compliance teams.
• Confidently upgrade integrations when you are ready.