Opening data without architecture opens risk

Open Finance promises that customers can share financial data with authorized third parties to receive better products. The promise is good. The implementation is delicate.

A poorly designed financial API does not only fail technically. It can expose sensitive data, break trust, and create regulatory responsibility.

Principle 1: consent as a first-class entity

Consent should not live as text in a user table. It should be its own entity:

type Consent = {
  id: string
  subjectId: string
  providerId: string
  scopes: string[]
  status: 'active' | 'revoked' | 'expired'
  grantedAt: string
  expiresAt: string
  revokedAt?: string
  purpose: string
}

Every data access should point to active consent. If consent expires or is revoked, derived tokens should become invalid.

Principle 2: scopes that mean something

Scopes like read_all are convenient and dangerous. Better separation:

• accounts:read
• balances:read
• transactions:read:90days
• identity:read
• payments:initiate
• payments:status

This makes honest experiences possible. A budgeting app does not need permission to initiate payments. A credit provider may need 12 months of transactions, not indefinite access.

Principle 3: immutable audit

The system should record:

• Who requested access.
• Which consent authorized it.
• Which endpoint was called.
• Which fields were delivered.
• When it happened.
• Which client or integration used it.
• The result of the call.

Audit logs are not debugging logs. They have stricter requirements: integrity, retention, search, and access control.

Principle 4: normalized data separate from raw data

Store the original event. Then create a normalized version.

Raw data enables audit. Normalized data enables product.

Example:

{
  "raw_description": "PAGO POS 000482 SUPERM NACIONAL",
  "merchant_name": "Supermercado Nacional",
  "category": "groceries",
  "amount": 2450.75,
  "currency": "DOP",
  "confidence": 0.94
}

If the model changes, you can reprocess. If a customer disputes a classification, you can return to the source.

Principle 5: short-lived tokens and rotation

In financial APIs, long-lived tokens are security debt. A reasonable base:

• Short-lived access tokens.
• Rotating refresh tokens.
• Revocation by consent.
• Planned signing-key rotation.
• mTLS or equivalent mechanisms for high-risk clients.
• Rate limiting by client, user, and endpoint.

The goal is to limit damage when something leaks.

Principle 6: idempotency in money operations

For payment initiation or money movement, every request should carry an idempotency key. If the client retries after a timeout, the system cannot duplicate the transaction.

Idempotency-Key: pay_01J0R7W5F9ZK8N

The backend should return the same result for the same logical operation.

Principle 7: real revocation

Many platforms let users “disconnect” an app, but internal jobs keep using snapshots or secondary tokens. That is not real revocation.

Revocation should:

• Invalidate tokens.
• Stop scheduled syncs.
• Record the event.
• Notify the third party when applicable.
• Prevent future use of data except for legal or contractual obligations.

How we apply it at SSD

When we design financial integrations, we use a clear separation:

• Connector layer.
• Consent layer.
• Secrets vault.
• Raw event lake.
• Normalized model.
• Product APIs.
• Audit and monitoring.

This looks like more work at the beginning. It is. But it prevents rebuilding everything when the first new bank, first audit request, or first incident arrives.

Open Finance is not won by publishing endpoints. It is won by proving every data access has permission, purpose, and traceability.

Context sources

• IDB: open finance
• Superintendencia de Bancos: open banking in the DR