Transaction Normalization as Internal Infrastructure.

MapleSchema is a schema-first normalization layer for fintech platforms. It sits between upstream providers and downstream systems, so format changes don’t become rewrites.

Outputs are deterministic and include stable, anonymized, idempotent transaction IDs to prevent duplicates without exposing internal customer or account identifiers.

Licensed for internal use • Privacy-conscious processing • Deterministic outputs

How it works

Upstream: aggregators / bank feeds → MapleSchema: normalize, dedupe, stable IDs → Downstream: ledgers, analytics, reporting, exports.

Upstream to MapleSchema to Downstream flow diagram

MapleSchema does not replace your providers or analytics layer. It isolates upstream volatility from downstream systems.

Licensed for internal platform use. Not a consumer-facing service.

🔀 One Canonical Schema

Normalize across aggregators and bank feeds into a stable contract your systems can rely on.

🧾 Deterministic & Audit-Friendly

Predictable transformations, structured failures, and explainable outputs designed for operational use.

🕶️ Privacy-Conscious by Design

In-memory processing, minimal logging, and no reliance on internal customer identifiers for deduplication.

🧱 Fits Your Existing Stack

MapleSchema isolates upstream volatility from ledgers, analytics, reporting, and exports.

🔓 Reduce Vendor Coupling

Avoid baking provider-specific fields into downstream systems. Normalize once, then move.

🍁 Canada-Oriented Constraints

Built with common Canadian open-banking constraints in mind: data minimization, auditability, and residency.

Example: One space, two views

Toggle between a representative upstream payload and the canonical contract your downstream systems can rely on. Optional insights.* fields are annotations only.

Upstream raw JSON

Provider-specific structure • Unstable identifiers

Provider-specific structure and identifiers you don’t want to leak downstream. (This sample is tuned so the canonical view matches the values below.) 

{
  "Data": {
    "Transaction": [
      {
        "AccountId": "chq_001",
        "TransactionId": "stmt_line_1842",
        "TransactionReference": "stmt_line_1842",
        "Amount": { "Amount": "7.24", "Currency": "CAD" },
        "CreditDebitIndicator": "Debit",
        "Status": "Booked",
        "BookingDateTime": "2026-01-14T19:22:11Z",
        "ValueDateTime": "2026-01-14T19:22:11Z",
        "TransactionInformation": "TIM HORTONS #0059 / LONDON ON",
        "ProprietaryBankTransactionCode": { "Code": "POS", "Issuer": "rbc_ca" }
      }
    ]
  },
  "Links": { "Self": "https://api.flinks.com/transactions" },
  "Meta": {
    "TotalPages": 1,
    "FirstAvailableDateTime": "2026-01-01T00:00:00Z",
    "LastAvailableDateTime": "2026-01-31T23:59:59Z",
    "InstitutionCode": "rbc_ca",
    "AggregatorCode": "flinks",
    "InputTimezone": "America/Toronto",
    "MappingMethod": "institution_mapper_v1"
  }
}

MapleSchema exists to isolate downstream systems from upstream volatility like this.