Security

This section covers Quovo’s policies and recommendations surrounding data security, API usage and account syncing. Quovo considers information security to be its highest priority at all times. We uphold the highest industry security standards and, as such, we reserve the right to enforce the responsible and secure use of our products as appropriate. These security standards position Quovo and our clients to best protect the sensitive financial data and personally identifiable information (PII) of end users. As outlined here, use of the Quovo API is authenticated with API access tokens, generated and maintained with the /tokens endpoint. All other endpoints are authenticated with access tokens, with the exception of the /me endpoint, which is used to fetch information on the API user and update their API password. Quovo recommends generating a new API access token every hour, and as such this is the default expiration time for tokens unless otherwise specified. We strongly discourage creating API access tokens that last longer than a day. We recognize that tokens with longer expiration times can be useful during development and testing periods, and the practice of sharing development tokens among developers is common; however, if multiple environments are required we urge clients to contact us to create a dedicate API user (and associated end user group) limited to test institution data. API access tokens should be stored carefully. Therefore, we strongly discourage hardcoding API access tokens in your codebase for any purpose. By default, Quovo limits each API user to 10,000 API calls on a rolling one-hour basis. If you run over this limit, subsequent calls will return with an [ERROR CODE], until the rolling one-hour sum of calls decreases below 10,000. Note that this limit does not include GET calls made to the /sync endpoint, which can be numerous when polling for sync status. Quovo believes that this rate limit is sufficient for the majority of use cases and reduces the damage that bad actors can potentially cause. If you find that you require more than 10,000 API per hour, please contact us. Our implementation team can work with you to determine whether an increased rate limit is appropriate for your account volume and use case. In order to minimize potential security risks involving sensitive client data, Quovo has a data retention policy targeting stale connections. For our purposes, a stale connection is any connection that has not had a “good” sync for several months. This will usually be due to user-actionable issues like incorrect login credentials or missing MFA answers. If a stale connection has not synced to a “good” status in the last 90 days, we will clear any login credentials or MFA answers on the connection. This will not delete any financial data within the connection’s accounts. If the stale connection continues to have a non-“good” status 180 days after its credentials have been cleared (i.e. it has been 270 days since the connection’s last “good” sync), we will delete the connection. This will delete any financial data attached to the connection or its accounts. During the account syncing process, end users must supply credentials to Quovo in order to connect to an institution on their behalf. Given the sensitivity of these credentials, Quovo maintains automated security checks to protect against possible bad actors from breaching a user’s financial accounts with brute force methods. If an end user has attempted to sync accounts on Quovo with incorrect credentials 15 times over a four hour window, that user will be blocked from syncing any accounts on Quovo for another four hour period. This holds true for both API-only syncs and syncs through Quovo Connect. For an individual connection, end users have two attempts at entering the same credentials or MFA responses—if either is wrong, Quovo will not attempt a third sync until either the credentials or responses have been changed. In both cases above, blocked subsequent sync attempts on behalf of that user will return [ERROR]. Quovo’s data hierarchy is build to mimic real life financial account ownership structures. Individuals (Quovo “users”) have relationships (“connections”) with financial institutions (“institutions”), where multiple accounts (“accounts”) exist. As such, each Quovo user should correspond to a single end user on your platform or at your enterprise. In other words, a Quovo user is a person. Quovo users should not be created for each end user’s various connections. One-to-one correspondence between Quovo users and physical end users is the most effective and secure way to manage users and connections, and is the easiest way to comply with your (and your users’) obligations under our Terms of Use. When a sync ends in a nongood status, it may mean a user needs to re-authenticate the account. In this instance, Quovo recommends maintaining the existing connection by addressing the authentication issue, rather than deleting the connection and replacing it with a new one. There is no need to delete accounts in order to resolve connection issues. We strongly discourage you from storing user credentials on your servers once they have been passed to Quovo. We have gone to great lengths to build the safeguards necessary to ensure that credentials are stored securely. Storing credentials on your servers exposes you and your users to unnecessary risk. Quovo also discourages syncing unnecessary connections. Storing superfluous data on your systems increases security risk. Quovo authenticates via TLS. We recommend using TLS 1.2, although TLS 1.3 support is on our roadmap. When using TLS, it is important to always validate all TLS certificates and make sure they are issued by Quovo. We also recommend handling all TLS errors and values.