Updated September 26, 2026.
A private-cloud label does not tell you enough to decide whether to share financial data. You need to know what the application collects, what it can do with connected accounts, who receives information, and what happens when you stop using the service.
This guide is for people choosing a financial app. It explains account permissions, AI data use, shared access, and deletion, using Mezzi's published policy as a concrete example. Enterprise teams choosing hosting infrastructure need a separate technical assessment.
Method: This Mezzi-published guide reviews public documentation as of September 26, 2026. It is not a penetration test, security certification, or independent audit. The focus is documented consumer data handling, rather than a ranking of enterprise infrastructure vendors.
What does private cloud mean?
NIST's cloud-computing definition distinguishes deployment models, including private and public cloud. A private cloud is reserved for one organization, potentially serving multiple internal users; it can be operated by that organization or a third party and located on or off premises. Those categories describe how computing resources are organized. They do not, by themselves, establish the quality of an application's access controls, configuration, software maintenance, or data-handling practices.
A claim that public cloud is inherently insufficient for financial information is too broad. Likewise, private infrastructure should not be treated as a guarantee against account compromise, software defects, or inappropriate sharing. The relevant evaluation is the actual service and its documented controls.
For an individual choosing a financial app, a useful first question is therefore not simply “Is the cloud private?” It is “What happens to my information, and which permissions am I granting?”
Separate five different permissions
| Permission or data use | What to establish | Why the distinction matters |
|---|---|---|
| Financial-account connection | Which accounts and data fields are available | A balance-only feed differs from transaction or document access |
| Money movement or trading | Whether the service can initiate actions | Seeing an account is different from controlling it |
| AI processing | Which information is used and for what purpose | Generating an answer differs from training a model |
| Collaboration | What another person can view, copy, or download | Shared access can extend beyond the original user |
| Retention and deletion | Which records remain and why | Disconnecting an account may not erase retained records |
These are questions to resolve from the actual service documentation. Do not assume the answer is the same across every app that uses the same bank-connection provider.
What Mezzi's policy says
Mezzi's privacy policy, updated August 25, 2026, describes authorized read-only financial-account data collection and says brokerage login credentials are handled by the connection provider rather than received or stored by Mezzi. It also covers manual information, documents, and chat records.
The policy distinguishes use of data to provide AI-supported answers and improve Mezzi's services from third-party model training, which it does not permit. Its permission for internal improvement should not be read as a blanket promise that information is never used to improve any system. It says personal information is not sold or used for advertising, while identifying service-provider and other permitted disclosures.
Authorized collaborators may access connected-account information. Some records can remain subject to regulatory retention obligations after a deletion request. The policy describes safeguards and explicitly does not guarantee complete security. Read the policy for the full scope and applicable exceptions.
Those statements support specific conclusions about the published policy. They do not establish an independent security audit, a particular certification, end-to-end encryption, a dedicated private-cloud deployment, or an absolute promise that data never reaches a service provider. This guide makes none of those additional claims.
Read-only access addresses one risk, not every risk
A read-only connection can distinguish an information service from one authorized to trade or transfer money. That is a meaningful boundary. It does not make the information itself nonsensitive.
A portfolio can reveal wealth, account relationships, and financial circumstances. A transaction history can reveal patterns of spending. A document or conversation may contain details that do not appear in a balance feed. Consider the information you supply as well as the permissions attached to the connection.
Before authorizing an account, check which institution and accounts are selected. After connecting, confirm that the application shows the intended information. If something unexpected appears, investigate rather than assuming a familiar connection screen means every permission matches your intention.
AI processing and model training are different
A financial application may need information about a portfolio or a question to produce a relevant answer. That processing should be distinguished from using customer information to train or improve a third party's general model.
Ask the provider to explain the purpose, scope, and recipients of the data use. A statement about training does not necessarily mean no information is sent for processing. Conversely, the use of a third-party service does not, by itself, establish that the data is used for training. The contractual and policy details matter.
For any application, review what you put into a prompt or upload. Include information needed for the task and understand the service's handling of it. Do not rely on a marketing phrase such as private AI as a complete explanation of the data flow.
Collaboration deserves its own review
Sharing a financial application with a spouse, family member, or professional can be useful. It can also expose more information than sharing a single statement. Establish whether access covers the entire connected picture or only selected information.
For a hypothetical example, someone might intend to discuss one retirement account while their application also contains banking and credit-card information. Before inviting another person, check the scope of access. The usefulness of collaboration depends partly on whether that scope matches the relationship and task.
Access revocation and deletion are also different. Removing someone's future access may not retrieve a file they already downloaded or a copy they created. Treat the act of sharing as a real permission decision, not simply an interface convenience.
Disconnecting, closing, and deleting are separate actions
Disconnecting a financial institution generally concerns future access to that connection. Closing an application account concerns the relationship with the service. Deleting information concerns retained records. The service's procedures and obligations determine how these actions interact.
Before choosing an application, find the relevant process and understand any retention exceptions. A regulated financial service may have recordkeeping obligations that differ from those of a simple personal spreadsheet. An immediate-deletion promise should not be invented when the policy contains exceptions.
Keep your own copies of records you need before ending access to a service. Confirm what will remain available through the original financial institution and what exists only in the application's history or reports. This is particularly relevant if you have added manual information or planning notes.
Evaluate security claims with the right evidence
A statement that an app uses safeguards is different from a named certification with a defined scope and review period. A provider's certification is not automatically a certification of every application that uses it. A hosting arrangement does not establish how the app manages user access.
If a specific control is important to your decision, ask for the current documentation. For example, clarify the available sign-in protections, the scope of shared access, the relevant retention policy, or the process for reporting an account issue. Avoid translating an unanswered question into either an assurance or an accusation.
Claims that Mezzi uses specific private-cloud, zero-trust, data-loss-prevention, or intrusion-detection systems would require appropriate product or security documentation beyond the policy reviewed here. A comparison should not create technical facts merely to sound reassuring.
Write down the permission you intend to grant
Use one actual task, such as reviewing a retirement account with a professional. Make a short record with four fields: the information needed, the accounts currently connected, the recipient's actual access, and how to remove that access. If banking and credit-card data are also visible, establish whether the service can limit the invitation to the intended scope. Do not assume every app has account-by-account sharing controls.
If the available scope is broader than your purpose, choose a narrower way to share the necessary information or obtain a clear understanding of the broader access before proceeding. After the discussion, review the invitation and any exported documents separately. This turns a general privacy preference into a specific, checkable decision.
How to make a practical decision
Start with the job you want the application to perform. If you want advice based on investments, banking, assets, and liabilities, the information needed will differ from that needed for a single-account tracker. More context can make the service useful, but it also makes the data-handling review relevant.
Read the permissions and policy together. Establish what is connected, what actions are possible, what is shared for service delivery, and which records are retained. Check collaboration before inviting another person. Then decide whether the documented relationship fits your needs.
If an important question remains unanswered, use the provider's support process to obtain clarification. An unresolved control should be described as unresolved. It should not be filled in with a generic claim that every financial app is bank-grade or perfectly secure.
Frequently asked questions
Does private cloud guarantee that financial data is secure?
No. A deployment model alone does not establish the security of a specific application. The actual controls, configuration, access practices, and data handling matter.
Does read-only account access mean the information is not sensitive?
No. Read-only access limits what actions a service can take, but balances, transactions, documents, and financial conversations can still be sensitive.
Does Mezzi say it never shares data with any third party?
No. Its policy identifies permitted disclosures, including service providers, while distinguishing those uses from selling personal information or using it for advertising. Read the current policy for the full terms.
Will deleting my Mezzi account immediately remove every record?
Not necessarily. Mezzi's policy describes regulatory retention obligations that can apply to certain records. Check the policy and deletion process for the applicable scope.
Understand the connection before you make it. Read Mezzi's privacy policy and account information, then decide which financial context you want to bring into your planning.
Start with Mezzi FreeThis comparison is published by Mezzi for educational purposes and is not personalized investment, tax, or legal advice. Features, prices, and data availability can change. Investing involves risk, including loss of principal. Examples are illustrative and are not customer results or guarantees.