Security practices
Last updated June 2026
Security is foundational to a payments platform that moves digital assets. This page describes the practices Plaidly Labs, Inc. ("Plaidly") uses to protect the Service, your account, and the funds and data that flow through it. It complements our Terms of Service and Privacy Policy. No platform can promise perfect security, but we engineer in depth and continuously improve our controls.
1. Infrastructure
Plaidly runs on hardened, container-based infrastructure deployed through an automated, peer-reviewed GitOps pipeline. Production workloads are isolated by network policy and namespace, and run with least-privilege service accounts. We separate environments (production, staging, development) and restrict production access to a small set of authorized engineers. Infrastructure is defined as code, so changes are versioned, reviewed, and auditable rather than made by hand.
2. Encryption
All traffic to and from the Service is encrypted in transit using TLS with modern cipher suites; HTTP is redirected to HTTPS, and security response headers are enforced at the edge. Sensitive data is encrypted at rest, and secrets, API keys, and signing material are stored in a dedicated secrets manager rather than in source code, configuration files, or container images. Cryptographic keys are rotated on a defined schedule and on suspicion of compromise.
3. Key Management for Custodial Wallets
Where custodial features are enabled, the private keys that control custodial wallets are among our most sensitive assets, and we treat them accordingly. Keys are generated and stored using dedicated key-management and, where applicable, hardware-backed or HSM-grade controls. Signing operations are isolated from general application code and gated by strict authorization. We apply least-privilege access, separation of duties, and monitoring around any operation that can move funds, and we design money-movement flows so that no single compromised component can quietly drain balances. Non-custodial configurations leave key control entirely with you; see the wallet section of our Terms of Service.
4. Access Controls
Access to systems and data follows the principle of least privilege. Internal access requires strong authentication, including multi-factor authentication, and is granted by role and scoped to need. Administrative and production access is limited, logged, and periodically reviewed. API access uses scoped keys that you can rotate and revoke; we recommend separate keys per environment and integration, and that secret keys never be exposed in client-side code or public repositories.
5. Monitoring and Logging
We collect application, infrastructure, and security telemetry centrally. Metrics, logs, and alerts feed dashboards and automated alerting so that anomalies — unusual authentication patterns, error spikes, abnormal on-chain or settlement activity, or resource exhaustion — are surfaced quickly to the responsible team. On-chain transactions are continuously monitored for confirmation status and reconciliation, and suspicious transactional activity is flagged for review.
6. Secure Development
Changes go through code review and automated checks before release. We use dependency scanning to track and remediate vulnerable libraries, follow secure-by-default patterns in our APIs and SDKs, and design money-movement logic — transfers, sweeps, and settlement — to be idempotent and auditable. Our API is specification-first, which keeps request and response validation consistent across clients.
7. Responsible Disclosure
We welcome reports from security researchers and treat them as a vital part of keeping the platform safe. If you believe you have found a vulnerability, please report it privately and give us a reasonable opportunity to remediate before any public disclosure. Please do not access, modify, or exfiltrate data that is not yours, degrade the Service, or run intrusive automated testing against production. Acting in good faith under these guidelines, we will not pursue legal action against you.
Report a vulnerability
Email [email protected] with a clear description of the issue, the steps to reproduce it, the impact, and any proof-of-concept details. For sensitive reports, request our PGP key in your first message and we will provide a secure channel. We aim to acknowledge reports promptly, keep you updated on remediation, and credit researchers who report valid issues responsibly.
8. Compliance Posture
We align our security program with widely recognized industry frameworks and best practices, and we support the regulatory obligations that come with handling payments and digital assets, including KYC/KYB, anti-money-laundering, and sanctions-screening controls implemented with our compliance partners. We maintain data-handling practices consistent with the GDPR and CCPA as described in our Privacy Policy, and we work with reputable custody, identity, and infrastructure providers that meet appropriate security standards.
9. Vendor and Third-Party Risk
The Service depends on third parties such as cloud hosts, custody providers, RPC and node providers, and identity-verification vendors. We evaluate the security posture of critical providers, scope the data and access they receive, and govern those relationships contractually. We cannot, however, control public blockchain networks, which operate independently of Plaidly.
10. Incident Response
We maintain an incident-response process to detect, triage, contain, eradicate, and recover from security events, followed by a post-incident review to address root causes. Where an incident affects your data or funds and notification is required by law or contract, we will notify affected users and, where applicable, regulators, with relevant details and guidance as the situation is understood.
11. Your Role in Security
Security is shared. Protect your account credentials and API keys, enable multi-factor authentication, rotate keys you suspect are exposed, verify destination addresses and chain selections before transacting, and keep your own integrations and dependencies up to date. Remember that on-chain transactions are generally irreversible.
12. Contact
For security questions or to report a vulnerability, email [email protected]. For general help, use our support channel. See also our Terms of Service and Privacy Policy.