Metro MOGO API integration (FDX & OpenBanking)

1. Authorization & session

Self-enrollment, login, MFA prompt handling and session refresh. Token vault uses AES-256 at rest; sessions rotate on a 30-minute idle window to match typical home-banking norms.

Use: a single sign-in surface for a member-facing finance app or a one-shot batch job for an accountant.

2. Transaction history API

Pulls posted and pending entries with amount, posted_at, memo, category_hint and balance_after. Supports date-range, account-filter and cursor pagination.

Use: monthly bookkeeping reconciliation, anomaly detection, or PFM categorization.

3. Statement export

Generates per-month statement payloads as JSON, CSV, OFX 2.x or PDF mirroring the original statement layout. Useful where mobile apps do not natively offer CSV download (a common gap reported across US banking apps).

Use: tax preparation, audit trails, lender doc collection.

4. Bill pay & payees

Lists scheduled and historical payments, payee directory entries and confirmation IDs; supports a read-only mode plus an opt-in write mode for scheduling, gated behind explicit member consent.

Use: cash-flow forecasting, payment reminders, vendor reconciliation.

5. Alerts webhook

Subscribes to balance-threshold, large-debit, deposit-posted and login alerts and replays them as signed webhook events to your endpoint. Includes a replay/idempotency key per event.

Use: trigger downstream accounting events the moment a deposit clears.

6. Documentation & tests

OpenAPI 3.1 spec, Postman collection, sample request/response fixtures, a pytest or jest suite hitting a recorded fixture set, and a one-page compliance brief covering Section 1033 and FDX field mapping.

Use: hand the bundle to an internal engineering team and skip weeks of discovery.

Scenario A — Small-business reconciliation

A Springfield-area landscaping LLC banks at Metro Credit Union for its operating account and uses QuickBooks Online for books. The MOGO transaction history API pulls posted entries nightly, normalizes them into the FDX Transactions shape, and feeds QBO via its Bank Feeds endpoint.

End-to-end: POST /auth → GET /accounts → GET /transactions?from=...&to=... → FDX normalization → QBO bank feed push. Result: the owner stops typing checks into a spreadsheet and the books close two days faster each month.

Scenario B — Mortgage application income verification

A regional lender needs 60 days of statements plus pending transactions to assess affordability. With the member's authorization, the statement export module produces a signed PDF bundle plus a JSON breakdown of payroll deposits, broken down by counterparty memo line.

This replaces the older “ask the member to upload PDFs and re-key the totals” loop with a single FDX StatementRequest + Transactions call and an audit trail tied to the consent timestamp.

Scenario C — PFM and budgeting app

A consumer-facing budgeting product wants to add Metro CU members alongside Plaid- and Akoya-covered institutions. Our connector exposes the same FDX-shaped /accounts, /transactions and /balances endpoints the PFM already consumes from aggregators, so adding Metro CU does not require a fork of the data layer.

This long-tail PFM — covering small credit unions that aggregators sometimes miss — is a recurring request now that more than 114 million US accounts are connected via FDX-aligned APIs as of Q1 2025.

Scenario D — Internal treasury dashboard for a community non-profit

A non-profit holds an operating share-draft account, a money market, and two certificates with Metro CU. The balance-sync module runs every 15 minutes and pushes a single normalized balance JSON into Grafana via Prometheus push gateway; the alerts webhook fires when any account falls below a configurable threshold.

Scenario E — Card-not-present fraud monitoring

The pending-transactions feed plus the alerts webhook are wired into a rules engine; large unrecognized debits within minutes of a login event from a new IP trigger an SMS to the member and a soft-hold flag for the credit union's fraud queue. The signed webhook envelope carries a replay-protection nonce so duplicates are dropped silently.

Login + token exchange (Python pseudocode)

# Authorize a member-granted Metro MOGO session
POST /api/v1/metro-mogo/auth
Content-Type: application/json

{
  "username": "",
  "password": "",
  "mfa_token": "",
  "client_id": "openfinance-lab/integration",
  "scope": ["accounts:read", "transactions:read", "statements:read"]
}

200 OK
{
  "access_token": "eyJhbGciOi...",
  "refresh_token": "rt_...",
  "expires_in": 1800,
  "consent_id": "csn_2026_05_11_abc123"
}

Transaction history (Node.js pseudocode)

// Pull 30 days of transactions for a share-draft account
GET /api/v1/metro-mogo/accounts/{account_id}/transactions
  ?from=2026-04-11&to=2026-05-11
  &status=posted,pending
  &cursor=eyJwYWdlIjoxfQ==
Authorization: Bearer 

200 OK
{
  "items": [
    {
      "id": "txn_8842",
      "posted_at": "2026-05-10T14:22:11Z",
      "amount": -42.17,
      "currency": "USD",
      "memo": "ACH DEBIT - CITY UTILITIES",
      "category_hint": "Utilities",
      "balance_after": 1284.55,
      "status": "posted"
    }
  ],
  "next_cursor": null,
  "fdx_version": "6.0"
}

Statement export + webhook (curl + payload)

# Request an April 2026 statement
curl -X POST https://api.openfinance-lab.com/v1/metro-mogo/statements \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"account_id":"acc_001","period":"2026-04","format":"pdf+json"}'

# Webhook fan-out when ready
POST https://yourapp.example.com/hooks/statement
X-OFLab-Signature: t=1715512345,v1=...
{
  "event":"statement.ready",
  "consent_id":"csn_2026_05_11_abc123",
  "statement_url":"https://...signed-url...",
  "summary":{"deposits":3,"withdrawals":18,"closing_balance":1242.38}
}

Error handling & retries

Errors follow an RFC 7807 application/problem+json envelope with type, title, status, detail and an incident_id. The SDK retries on 429 and 5xx using exponential backoff (250 ms, 500 ms, 1 s, 2 s, 4 s) and surfaces 401 as a refresh-token signal rather than a hard failure. Idempotency keys are required on every write endpoint.

Compliance & privacy

Metro Credit Union is a US-chartered credit union, so the regulatory perimeter for any integration sits inside US federal financial law — principally the CFPB Personal Financial Data Rights rule under Section 1033 of Dodd-Frank, finalized on 22 October 2024 and effective 17 January 2025. The CFPB also recognized the Financial Data Exchange (FDX) as a standard-setting body, and an Eastern District of Kentucky court enjoined enforcement in late October 2024 while a reconsideration rulemaking opened in August 2025. Our integrations are built to satisfy the stricter of the published rule and any successor text.

• Member-granted consent recorded with a consent_id and timestamp, revocable at any time.
• Data minimization: only requested scopes are returned; sensitive fields (full account numbers, PII) are tokenized at the boundary.
• FDX v6 field mapping for transactions, balances, statements and customer profile so downstream systems treat Metro CU identically to other US institutions.
• NCUA § 748 information-security expectations and GLBA Safeguards Rule patterns applied to transport (TLS 1.2+) and at-rest encryption.

Risk controls included

• Per-consent rate limits and anomaly detection on login churn.
• Append-only audit log of every API call, signed and exported nightly.
• Quarterly key rotation and a documented incident-response runbook.
• Optional data-retention windows (1 day, 30 days, 1 year, indefinite) per deployment.
• Aggregator-style fallback: when Metro CU is also reachable through MX, Plaid or Akoya, the same SDK can switch transport without changing the consumer's contract.

About OpenFinance Lab

We are an independent studio focused on app protocol analysis and OpenData / OpenFinance API integration for fintech, banking and adjacent verticals. Our engineers come from banks, payment gateways, mobile-app reverse-engineering labs and cloud SRE backgrounds, and the studio operates under written client authorization.

• Specialties: financial & banking apps, e-commerce, travel/mobility, social/OTT.
• Familiar with US (Section 1033, FDX, NCUA, GLBA), EU (PSD2, GDPR) and APAC (UPI, MAS) regimes.
• Deliveries in Python, Node.js, Go, Java and Kotlin; SDKs ship with tests and docs.
• Source-code delivery from $300 — runnable API source plus documentation; pay after delivery upon satisfaction.
• Pay-per-call API billing — use our hosted endpoints and pay only for the calls you make, no upfront fee.

Contact

To request a quote, submit a Metro MOGO integration brief, or discuss a multi-CU rollout that includes apps in the list above, open our contact page:

Contact page

Typical first response: same business day during US working hours.

Engagement workflow

1. Scope confirmation — you describe the data you need (e.g. transactions, statements, alerts) and the destination system.
2. Authorization & consent capture — written authorization or a sandbox you control; we record a consent_id.
3. Protocol analysis and FDX field mapping (2–5 business days).
4. Build & internal validation against fixtures and a live sandbox (3–8 business days).
5. Documentation, tests and compliance brief (1–2 business days).
6. First delivery: typically 5–15 business days end-to-end.

FAQ

What do you need from me to start a Metro MOGO integration?

How long does a first Metro MOGO API delivery take?

How do you keep Metro MOGO integrations compliant?

Can the same APIs work for other US credit union apps?