Bank statement analysis tools: a privacy and data-retention checklist
Compare upload permissions, AI use, retention schedules and deletion procedures before sharing merchant bank statements with an analysis vendor.
A merchant's bank statements can expose account details, customer payments, payroll and transfers to owners. Before uploading them to an AI analysis tool, establish who can use that information, where copies go and what happens when the work ends. A useful vendor comparison starts with written answers about those records, rather than a general promise that the service is secure. For brokers and funding teams, the purchasing test should cover the entire file. The original PDF, extracted transactions and downloaded report may follow different retention rules. A vendor that deletes the upload may still hold the analysis. A broker may also keep an exported copy after the vendor removes its own. The Federal Trade Commission's guide to protecting personal information recommends collecting only what a business needs and setting a written retention policy. That policy should explain what information stays, how it is protected, how long it stays and how it is disposed of. Applied to statement-analysis software, those questions give buyers a practical basis for comparison. Check permissions and permitted uses before upload First, distinguish a PDF upload from a bank connection. With an upload, identify the accounts, months and documents the service needs. With a connection, also ask whether access is one-time or ongoing, which accounts it covers and whether the permissions include payments. Confirm who has authority to share the business's records. Do not give a salesperson banking credentials to run a demonstration. The CFPB's archived financial-data-sharing guide distinguishes the service a customer chooses from the aggregator that may retrieve its data. It also warns that deleting an app does not stop data sharing. Although the guide dates from 2020, its practical distinction remains useful: canceling future account access and deleting information already collected are separate requests. Ask for the terms that apply to the exact product and account tier you would buy. Identify whether documents or extracted data may be used for model training, product improvement, human quality review or troubleshooting. Ask whether those uses are optional and whether changing a setting affects past uploads. A statement that data is excluded from model training leaves storage, support access and other permitted uses unresolved. Request a list of service providers that handle the file, including document extraction, model processing and storage providers. These are often called subprocessors. Ask which data each receives, where processing occurs and how changes are communicated. A model provider's policy alone cannot describe what the application vendor stores in its own database or logs. Then check access controls. The FTC's Start with Security guide recommends limiting access to people who need it, using separate accounts and protecting authentication. Ask the vendor to demonstrate staff permissions, multifactor authentication and removal of a departed user's access. Check how support personnel gain access and whether sensitive actions are recorded. If a vendor supplies an audit report, verify its period and scope instead of treating a badge as proof that every feature was assessed. Get a retention schedule and test the exit Request a schedule for original documents, extracted transactions, reports, support attachments, operational logs and backups. Each category needs a stated purpose, retention period and starting event. A period measured from upload can produce a different deletion date from one measured from account closure. Ask what happens to inactive accounts, unsuccessful applications and files used only for a trial. Separate removal from the active product from removal in backups. Ask when backup copies expire, who can access them and how deleted records are handled if a backup is restored. Also ask which legal or contractual exceptions can delay deletion. Obtain the reason and scope of an exception rather than accepting indefinite retention for every file. Applicable duties depend on the business, records and jurisdiction; this guide is operational guidance, not legal advice. Before paying for a full rollout, use a synthetic sample that contains no real customer information. Test the export and deletion process. Check whether the export includes the source document, transaction data and corrections you need to retain. Record how to request deletion, who can authorize it and what confirmation the vendor provides. A completed test can verify the visible workflow, but it cannot independently prove that every backend copy has disappeared. Apply the same review to Plutus. Its published privacy policy says application data is typically retained for seven years, allows deletion requests subject to legal retention requirements and says anonymized data may be used to improve its models. Buyers should ask how those statements apply to their files and contract. They should not infer immediate deletion or a blanket ban on model improvement from the availability of an analysis tool. Keep this vendor review separate from the credit assessment. The bank-statement underwriting guide covers deposits, payment obligations and cash stress. The funder-ready merchant-file guide covers assembling the application evidence. Neither replaces an agreement about who may retain or reuse that evidence. Opinion Make unresolved data terms a purchasing condition If the vendor cannot explain a material retention or reuse term, keep real merchant files out of the trial until it answers. Assign one person to record the response, the governing contract version and any exception your team accepts. That record gives the next reviewer a specific decision to check when the vendor changes its terms. Read more funding operations guides at plutusai.net .