Personal Card Reimbursements: Security Brief

Prepared for Legal, Privacy, and Compliance

Sometimes employees have to use a personal card for business expenses. The problem: submitting reimbursements for expenses on personal cards used to be a pain. Ramp's Personal Card Reimbursements make this process easy. Employees can connect their personal card via Plaid and choose which business transactions to submit for reimbursement.

Data flow overview

Personal Card Reimbursements data flow overview

Product overview: personal card reimbursements

When an employee chooses to link a card, Ramp uses Plaid to retrieve a bounded window of recent transactions and shows a limited transaction summary in the Ramp app. The interface is limited to the data fields needed to identify the charge, such as merchant, amount, date, currency, and pending status. This data is not visible to the employee's manager, or company admins or owners, until the employee imports the transaction data to Ramp.

The employee can select one or more transactions to create a personal card reimbursement, after which the reimbursement enters Ramp's standard approval workflow. Ramp does not require a card connection to submit reimbursements and does not retain personal card or account metadata as part of the reimbursement record. Learn more about how to use this feature in our Help Center article.

Ramp's overall security posture

Ramp maintains a SOC 2 Type II report which provides validation from an independent third-party auditor that our security program meets industry standards to keep your data protected. This report is updated on an annual basis—you can download the latest version and learn more about our security program at trust.ramp.com.

Threat model: personal card reimbursements

Some of the key privacy and security risks we considered and worked to mitigate when designing this feature include:

To help mitigate these risks, Ramp designed the Personal Card Reimbursements feature to limit the personal data collected and stored, protect credentials and reimbursement-linked data, restrict data access, and give employees clear control over the connection.

Mitigations

Access to personal transaction data

The connection is employee-initiated through Plaid. Once the connection is completed, Ramp retrieves transactions from the past 30 days. The transaction data is not accessible to other members of the employee's company (such as a manager, admin, or owner), until the employee creates a reimbursement from a personal card transaction in Ramp. The reimbursement record is tied only to the selected transaction used to support the reimbursement; unrelated personal account metadata is not saved by Ramp as part of that record.

Employees can choose to connect or disconnect their card at any time. When a user disconnects from Plaid or is offboarded by their organization, Ramp removes the connection from active use and deactivates the access token, rendering it unusable by Ramp or any other party.

Data minimization

Before a reimbursement is created, Ramp retrieves a 30-day recent transaction window and presents a limited summary of candidate transactions to the employee. Transaction IDs are hashed and cannot be used to fetch the original from Plaid. The selection interface is limited to fields needed to identify the charge, such as merchant, amount, date, currency, and pending status. Once the employee selects a transaction, Ramp stores the selected transaction information corresponding to that reimbursement (more info here). The created reimbursement record does not retain personal card or account metadata, aside from the account ID (which cannot be used to retrieve transactions without an access token, which we encrypt) and the account mask (last 4 digits). Plaid transaction data linked to a reimbursement follows the reimbursement record's lifecycle and deletion model.

Ramp also records limited merchant information from linked-card transactions, including transactions not selected for reimbursement through Ramp to identify and standardize merchant names and categories and improve merchant matching from personal card transactions. Ramp may retain the resulting merchant mapping for reuse in the matching process. The merchant data stored is limited to the merchant name only, and cannot be linked back to the user.

Protecting stored data

Credentials used to access the linked-card connection are encrypted at rest using a dedicated key domain separate from other Ramp encryption keys. Data is transmitted over encrypted connections (TLS 1.2+ between Ramp, user, and Plaid. More info on how Plaid handles data found here). Ramp maintains controls designed to prevent monitoring or logging of transaction data from the recent transaction window before it has been imported to Ramp, except that limited merchant information may be processed through Ramp's merchant-matching and observability flow for matching and evaluation purposes, without explicit customer or transaction identifiers.

Retention and deletion

Pre-selection transaction data is encrypted and expires automatically. When a reimbursement tied to Plaid data is deleted, we delete the corresponding Plaid data, and the associate reimbursement is deleted in accordance with our retention policies. When a card connection is disconnected or a user is offboarded, Ramp removes the connection from active use and disables the connection from future use. Selected transaction data remains tied to the reimbursement record consistent with financial record-keeping needs. Merchant-matching results, containing only the merchant descriptor, lifecycle timestamps, and the corresponding Ramp merchant identifier, are retained for as long as the mapping remains active and continues to serve the merchant-matching function. These results are soft-deleted when the mapping is no longer active.