Skip to main content

Plaid Banking FAQ

Integration

How does Plaid connect to banks, and how is this secured?

Plaid is FCA-authorised as an Account Information Service Provider (AISP) and acts as a regulated Open Banking middleware layer. The bank-side connection uses OAuth 2.0 with short-lived access tokens and refresh token rotation, TLS 1.2/1.3 encryption in transit, and Strong Customer Authentication (SCA) enforced during the initial bank consent flow. Plaid is never given raw bank credentials — customers authenticate directly with their bank via the Plaid-hosted UI and consent to share specific account data.

Additionally, on the Access Coins side:

  • Access Coins does not store Plaid API credentials on the Coins server — these are held in an Azure Key Vault.

  • Access Coins never has access to banking credentials; authentication happens in a Plaid pop-up within Coins.

  • Longer-lived access tokens are never exposed to the web client — they are retrieved server-to-server and immediately encrypted before database storage.

  • Those tokens only return data when additionally authenticated against Access API credentials, so the token alone is not sufficient.

Plaid Data

What data does Plaid store?

Plaid stores account metadata (account number, sort code, account name, institution), transaction data (amounts, dates, descriptions, merchant info where available), and OAuth tokens. Raw bank credentials are never stored by Plaid.

Where does this data reside?

Plaid is US-headquartered (San Francisco). For EU customers, data is processed within AWS infrastructure.

How is data secured?

AES-256 encryption at rest, TLS in transit, SOC 1 Type II certified, with internal access controls and audit logging.

What is the data retention policy?

Plaid's default is to retain transaction data for a rolling period (Plaid makes up to 24 months of transaction history accessible, varying by bank). Plaid's own data retention for your linked accounts continues for as long as the connection is active.

Availability

Plaid targets 99.9%+ uptime and operates continuously with rolling deployments — there are no planned downtime windows for the Plaid platform itself. Note that availability for specific banks depends on those banks' own Open Banking API uptime. Bank-side maintenance (particularly weekend overnight windows) can temporarily affect connectivity. Real-time status is published at status.plaid.com.

Licensing

Plaid access is provisioned through Access Workspace (Hub) on a tenant basis rather than as a traditional Coins module licence (no licence required). Relevant keys will be provided by Access Coins to be added to the parameters (PLDHMAC, PLDSECID, PLDSUBID, PLDTENANTID — API credentials and tenant identifiers).

Architecture Overview

The Plaid integration does not expose any shared Plaid credentials to Coins instances. Instead, it uses the ERP division’s shared Azure API Management (APIM) layer as a secure intermediary.

High-level design

  • Coins instances communicate with Plaid via a shared APIM endpoint:
    https://api.erp.accessacloud.com/plaid/*

  • APIM acts as a secure relay (“Access Relay”), routing requests to Plaid.

  • The Plaid client credentials (client_id and secret) are securely stored in Azure Key Vault and are never exposed to Coins instances.

Authentication & request flow

  1. A Coins instance sends a request to APIM with:

    • HMAC-based Authorization header

    • X-Signing-Key-Id

    • X-Tenant-Id

  2. APIM validates the request. If required, it retrieves a signing key via the Token Generator API (app-token-generator-prod-v2).

  3. Signing keys are cached (TTL ~1 hour) to minimise repeated calls.

  4. Once validated, APIM injects the Plaid client_id and secret into the outbound request.

  5. APIM forwards the request to Plaid Production API (production.plaid.com).

  6. The response is returned to the Coins instance via APIM.

Security considerations

  • No customer data is persisted within this middleware; it functions purely as a TLS-encrypted pass-through.

  • Coins instances use instance-specific tokens generated by the internal ERP Token Generator (shared across multiple ERP products).

  • The design ensures:

    • Centralised credential management (via Key Vault)

    • No exposure of Plaid secrets to tenant instances

    • Tenant-level access control via signing keys

Penetration testing/assurance

  • While this specific component may not have been independently pen-tested, the Token Generator process is shared across multiple ERP products, many of which have undergone penetration testing. This provides indirect assurance over the authentication mechanism.

Infrastructure ownership

  • The APIM (“Access Relay”) is a shared ERP Azure resource (likely owned at platform level), although its use for Plaid is product-specific to Coins.

Networking

  • The endpoint used is publicly accessible over HTTPS.

  • Outbound IP whitelisting is typically not required for this integration.

  • If you require the fixed outbound IP address, please contact your delivery project manager/consultant.

Did this answer your question?