MapleSchema takes institution-specific open banking transaction payloads and turns them into one stable, opinionated schema your application can rely on across Canadian banks and aggregators.
Stop maintaining a different mapping layer for every institution. Target one schema. MapleSchema keeps pace with banks and aggregators as they roll out open banking.
Zero-retention by design: Canadian servers, no databases, no buckets, no write permissions. Payloads are processed in memory and destroyed immediately.
UTC timestamps, explicit direction, signed amount rules,
and deterministic behavior so your code behaves the same in every environment.
We normalize open banking transaction payloads from Canada’s top financial institutions
into a single transactions-v0.1 schema. UTC timestamps, explicit debits/credits,
and a stable field set — regardless of which bank or aggregator the data came from.
MapleSchema runs with no databases, no buckets, and no write permissions. Open banking payloads are processed in memory and destroyed immediately, making compliance and security teams very happy.
Hosted on Canadian servers with no persistence layers. Payloads never leave the country and cannot be captured or stored — even by mistake. Infrastructure is configured to disallow data-at-rest.
Security posture, zero-retention guarantee, IAM restrictions, and architecture diagrams — a ready-to-share compliance packet so engineers don’t need to build or document all of this themselves.
Same input → same output. Versioned fields, strict rules, UTC-only timestamps, and conservative categorization. A normalization contract your codebase can depend on across all supported institutions.
Keep your existing connections to banks and aggregators. Drop MapleSchema in front of your ingestion pipeline, POST raw open banking transaction payloads, and get normalized transactions back. No more hand-rolled mappers for each institution.
Start with the largest institutions and leading digital banks. As Canadian open banking APIs roll out across more institutions, MapleSchema adds new mappers while your application keeps talking to the same stable schema.
Clean UTC timestamps. Explicit direction semantics. Signed amount rules.
Opinionated naming. Boring consistency that saves real engineering time when you integrate multiple institutions.
This is a minimal example showing how to send an open banking payload to MapleSchema
and receive a normalized transactions-v0.1 response. The endpoint is stateless,
zero-retention, and designed for fast ingestion pipelines.
curl -X POST https://api.mapleschema.com/v0/transform \
-H "Content-Type: application/json" \
-d '{
"institution_code": "rbc_ca",
"transactions": [
{
"transactionId": "abc123",
"bookingDateTime": "2026-01-12T14:30:00-05:00",
"status": "BOOKED",
"type": "DEBIT",
"amount": { "currency": "CAD", "value": "18.42" }
}
]
}'
The example endpoint above is illustrative.
Open banking transaction payload (simplified):
{
"transactionId": "abc123",
"bookingDateTime": "2026-01-12T14:30:00-05:00",
"status": "BOOKED",
"type": "DEBIT",
"amount": {
"currency": "CAD",
"value": "18.42"
},
"merchant": {
"name": "UBER *TRIP HELP.UBER.COM"
},
"description": "POS 07/12 UBER *TRIP HELP.UBER.COM CA"
}
Normalized output (transactions-v0.1 schema):
{
"schema_version": "transactions-v0.1",
"meta": {
"received_at": "2026-01-12T19:30:01Z",
"adapter": "rbc_ca.v1",
"confidence": 0.98
},
"institution_code": "rbc_ca",
"transaction_id": "abc123",
"posted_at": "2026-01-12T19:30:00Z",
"authorized_at": null,
"amount": -18.42,
"currency": "CAD",
"direction": "debit",
"transaction_type": "card",
"original_description": "POS 07/12 UBER *TRIP HELP.UBER.COM CA",
"normalized_description": "Uber trip",
"merchant_name": "Uber Technologies",
"merchant_cleaned": "uber",
"status": "posted",
"category": null,
"country_code": "CA"
}
The full schema — including field definitions, enums, metadata rules, and adapter notes — is available in the Docs section.