Modo Próspera

Public information

Privacy policy.

What the beta processes, why it does so, how long data is kept, and the controls available to you.

Last updated: August 27, 2026

Modo Próspera is a beta personal-finance app for recording household cash activity, reviewing bank statement uploads, closing financial months, and understanding household spending. This policy explains what the beta handles and how to contact us about your data.

Who We Are

Modo Próspera is developed and operated by Presupuesto Apps, an individual developer based in Ecuador. The privacy point of contact is the support contact published at https://modoprospera.com/soporte/?lang=en; it is the contact designated to receive privacy questions and export or deletion requests. Because the operator is established in Ecuador, Ecuador's Ley Orgánica de Protección de Datos Personales (LOPDP) applies to this processing. Regional Privacy Rights below states the response commitments that apply to every request and what your own law adds where you live.

Regional Privacy Rights

The same policy applies wherever you use the beta. The in-app full-workspace export is available only to an effective owner when the workspace passes its complete export-authority checks. Any signed-in person with current export permission for a cash account can separately request an actor-scoped cash-ledger copy in the app; it returns only the cash movements, revisions, and period seals that person can export. A member or View-only user can request a verified access copy of other eligible personal data through the support contact. Neither path discloses workspace data the requester is not authorized to see. Deletion is described under Account Deletion and Export And Deletion. We answer a verified access or export request, and complete a verified deletion request, within 15 calendar days of receiving it. Where a deletion cannot complete on its own — because a household you own still has other active members, or holds shared or joint accounts — we tell you what is required and what we did instead of leaving the request open. Every 15-day window in this policy means calendar days.

Depending on where you live, your own law adds a frame to those commitments:

  • Ecuador. You may ask us to confirm whether we process your data, to give you access to it, to correct or delete it, to stop a particular processing, and to withdraw a consent you gave. If our answer does not satisfy you, you may complain to us through the support contact and to the Superintendencia de Protección de Datos Personales.
  • Brazil. The Lei Geral de Proteção de Dados Pessoais (Law 13.709/2018, LGPD) frames how we handle personal data about people in Brazil. Article 18 lists your rights: confirmation that we process your data; access; correction of incomplete, inaccurate, or out-of-date data; anonymization, blocking, or deletion of unnecessary or excessive data, or data processed in a way that does not comply with the LGPD; portability; deletion of data processed on the basis of your consent, except for the limited records this policy says are retained after deletion; information about the entities we have shared your data with; information about your option not to give consent and what follows if you decline; and revocation of consent. Use the support contact, which is our communication channel for data subjects. We have not appointed an encarregado. Uploading statements and closing months is processing you ask us to carry out; the optional features named in this policy rest on the separate consent each one asks for; security, abuse prevention, and the retained audit records described under Retention rest on our legitimate interest in operating the service safely. Personal data about you is stored and processed outside Brazil, including in the United States, as described under Service Providers. You may also complain to the Autoridade Nacional de Proteção de Dados (ANPD).
  • Mexico. The Ley Federal de Protección de Datos Personales en Posesión de los Particulares published on March 20, 2025, which replaced the 2010 law of the same name, frames how we handle personal data about people in Mexico. You may exercise the ARCO rights it describes — access, rectification, cancellation, and opposition — and withdraw a consent you gave, through the support contact. In practice, access is served by the account export, cancellation by account or workspace deletion, and rectification and opposition are handled case by case. You may also raise the matter with the competent Mexican data-protection authority.
  • European Economic Area and United Kingdom. Presupuesto Apps is established in Ecuador and has not appointed a representative in the European Union or the United Kingdom. The beta is not marketed in those regions. If you use it from there, write to the support contact for any access, correction, export, or deletion request; we handle it under the commitments stated above.

Elsewhere, your local data-protection law may give you additional rights; the support contact honors access, export, and deletion requests regardless of where you live.

Modo Próspera is intended for adults. It is not directed to children, and we do not knowingly process a child's personal data. If you believe a child's data reached the beta, write to the support contact and we will delete it.

What We Collect

When you use the beta, Modo Próspera may process:

  • account and workspace details, such as your sign-in identity, display name, household/business name, role, any legacy invitation metadata, session metadata, reporting-cycle settings, income-source schedules, financial-account labels/kinds/last-four metadata, your explicit account-currency confirmation and its bounded evidence reference, savings goals, transfer reviews, and setup-checklist state
  • statement and transaction details from files you upload, including dates, descriptions, beneficiaries, categories, amounts, and derived totals
  • cash movements you enter, including the cash account and cycle, date, direction, amount and currency, optional category and description, the person who recorded the movement, append-only correction or reversal history, and the household's period seal or no-activity assertion. This is household-authored, lower-assurance evidence; it is not a bank statement and does not become verified bank coverage
  • when you confirm an annual-history import, a server-encrypted copy of the statement bytes themselves, held in durable custody only until its deletion deadline, together with a statement-content SHA-256 fingerprint, exact storage-version evidence, bounded structural validation evidence, and deletion/absence proof; Statement Files describes the deadlines and the deletion proof
  • normalized annual-history evidence and user-confirmed statement-mapping templates retained after an import; a bounded mapper preview may show source cells back to you but is not retained
  • immutable, account/cycle-bound promotion snapshots that let an active published annual-history revision enter the normal monthly Cierre without re-uploading or reparsing the original file; these snapshots retain the contributing normalized rows and their source/adapter/mapping provenance
  • durable parsed financial evidence used to verify compatibility and data quality, including duplicate validated model packets, reviewed links between account/source/cycle/transaction/category records, and comparisons for identity, category, coverage, corrections, totals, exclusions, transfers, and readiness
  • month-close history, including receipts, insights, category totals, daily cash-flow totals, audit events, and exported transaction rows
  • beta feedback you submit in the app, plus limited app context that helps us understand the issue
  • security metadata, such as hashed session verifiers, coarse client labels, and aggregate Firebase App Check counts
  • if you separately opt in, strictly allowlisted statement-format demand telemetry described under Optional Demand Telemetry
  • coarse first-close, review, correction, reopen, second/third-close, and structured support-effort evidence described under Product Measurement; and, only with separate current research consent, a structured willingness-to-pay response

Household Membership And Current Sharing Controls

The protected client and backend include household invitations, member-role management, ownership transfer, and per-account grant controls. Each group is available only after its separately reviewed hosted capability is activated; while a capability is off, the server returns the same generic unavailable response and creates no record for it. Multi-party deletion-consent remains a separate, unavailable workflow and is not implied by these controls.

An owner can invite the intended Google-identified person as a Member or View only user. Acceptance is bound to that signed-in person and the exact current household generation. It creates the membership only and creates zero Vault principal, source custody, or sharing policy. Invitation acceptance creates zero financial-account grants. The app then makes a separate explicit Vault-enrollment request for that signed-in person; enrollment still creates no source custody or financial grant. An owner can later change Member/View only role with a revision-checked update. The changed role applies to the target's live session immediately. A recently reauthenticated owner can propose ownership transfer to an active member, and that recently reauthenticated member must accept. Ownership changes household administration only; it does not transfer, create, or widen private-account authority.

Household role and financial-account visibility are separate. A household role by itself does not reveal account details. A person sees the full details of an account only when that account was deliberately shared with them through an active per-account grant. The app labels the read-only household role "View only"; that role cannot change household or financial data. A person can ask for account access without choosing or learning a private account. Only a current principal of an account may choose that account and approve a narrowed grant, proactively create a grant, or revoke it. A household owner who is not that account's principal has no extra grant authority and receives no private account identity or count. The grantee can also revoke their own access. Removing and later re-inviting a person does not revive an old grant. An effective owner can end a non-owner's current membership by removing that person, and a Member or View only user can leave.

If the holder of a private cash account chooses to include it in the household close, the app asks for explicit consent. That consent contributes the exact net cash amount to the household-close aggregate visible to the effective owner. It does not reveal the account's identity, individual movements, category, description or note, date, or which shared income source, if any, the private movement is associated with. Configured income-source names and schedules remain ordinary workspace-shared data; this consent does not newly disclose them. Declining keeps that private cash contribution out of the close and does not change the account's permissions.

For an already-existing household membership, an effective owner can remove a non-owner member, and a member or View-only user can leave the household through the standalone leave action without deleting their Modo Próspera account. An owner cannot use that action to remove themself. A successful removal or leave ends the person's household access, revokes that person's active household sessions, and revokes applicable pending invitations. It also removes that person's optional unaggregated statement-format telemetry and consent, closed-test statement enrollment, and every saved mapping-template lineage they authored in that household. It does not delete the household's closed months, transactions, or audit history.

Feedback has a different lifetime from membership. A standalone leave or owner removal does not delete feedback that the person previously submitted in that household. It remains a household support record until the household is deleted, or until the feedback author deletes their entire Modo Próspera account.

Household membership does not relay a notification from one person's phone to another household member's phone. As described below, Notification Capture is attended and strictly opt-in, and Avisos are optional reminders computed locally on each device.

Notification Capture (Modo Automático)

Notification Capture is included in the current protected Android release as an attended, opt-in feature. It stays completely inactive until you make two separate, explicit choices: granting Modo Próspera notification access in Android's own system settings, and turning the feature on inside the app after its plain-language explanation. Either switch alone is not enough, and you can revoke either one at any time.

Android's notification-access grant is broad: Android delivers notification events to the listener without a bank-only scope. For each event, the app checks only the posting package name against its reviewed allowlist before reading the notification title or body. If the package is not allowlisted, the app ignores the event without reading, retaining, or transmitting its title, body, or other content; it does not enumerate installed apps. For an allowlisted package, recognized bank alerts are parsed on your phone into structured movement fields (amount, currency, merchant, time) and stored encrypted on the device. Raw notification text is retained only when an alert could not be parsed, so you can resolve it yourself, and that text is deleted when you do. Nothing read from an allowlisted notification ever leaves your phone: it is not transmitted to our service, not shared with your household, and there is no raw-notification "share this format" action. Captured movements never become financial truth by themselves — the monthly close over real statements remains the only authority — and you can erase all captured data at any time from the same screen that enabled it.

Notifications The App Sends (Avisos)

If you turn Avisos on, Modo Próspera can notify you when your financial cycle ends (one reminder, one follow-up, then silence for that cycle) and shortly before an income you scheduled is due. The optional budget family uses captured expenses to report threshold, pace, and category-budget signals and may celebrate a streak after at least three consecutive months closed under budget on that device. Budget and capture notices exist only on the capture-capable release surface described above; they carry their own switches and a hard per-cycle cap on capture notices, beyond which new captures land silently in the in-app capture inbox. Every aviso type is off by default and requires Android's own notification permission, and its financial content is computed on your phone from information the app already has. Before posting, the app may contact our service only to confirm that the stored session and household access are still valid. That check sends normal authentication and security request metadata, but not the financial notification content or notification payload. Android delivers the aviso on that device; Modo Próspera does not relay it to another household member's phone.

Inside the app, Avisos is a ledger of conditions that still exist, not an unread-message inbox. It can show a cycle that needs closing or decisions, an open household-access request, captured bank alerts waiting for review, and an upcoming income you scheduled. Actionable rows and their count disappear when the underlying situation is resolved, not when you read them; there is no unread flag or mark-all action. The upcoming-income information row can be dismissed and restored on that device.

How We Use Data

We use this data to:

  • create previews from uploaded statements
  • record, correct, reverse, and seal the household cash activity you provide, while keeping it visibly distinct from verified bank-statement coverage
  • help you review uncertain transactions before closing a month
  • save month-close history for your household
  • stage normalized annual history and let you reuse a mapping you confirmed
  • support export, deletion, feedback, and account-management workflows
  • protect the service from replayed sessions and unverified app requests
  • improve the beta product based on feedback and reliability signals

No Sale Or Ads Use

Modo Próspera does not sell personal data.

Modo Próspera does not use personal data for advertising or share personal data for ads.

Statement Files

The closed-test annual-history flow is available only to a server-allowlisted, time-boxed Google Play cohort of at most 20 members and only for financial accounts classified PRIVATE. Shared and joint accounts are outside this closed-test profile. The Android app lets you select a statement of at most 5 MiB. The transient checks described below parse at most 2,500 transactions; the durable annual-history path admits at most 25 MiB and 100,000 normalized movements on the server, so the app's 5 MiB limit is the one you meet in practice. The profile expires on October 31, 2026 unless it is separately reviewed and renewed, and Modo Próspera can switch it off earlier.

Modo Próspera handles the raw bytes of a statement in two different ways, and which one applies depends on what you asked for:

  • Transient. The monthly-close preview, and the structural inspection that runs before an annual-history import is staged, receive the raw bytes over TLS and process them in request memory and ordinary hosting/platform request handling. Those paths create no intentional durable copy of the original statement.
  • Durable and encrypted. When you stage an annual-history import, Modo Próspera keeps an encrypted copy of the statement so it can be parsed away from the app's own service, and deletes it under the deadlines and deletion proof described in Durable Encrypted Custody For Annual-History Imports below. Earlier revisions of this policy described every statement path as transient; that is no longer accurate for annual-history imports.

When you share a statement from another Android app, that app's original content-URI permission is transient; Modo Próspera does not retain that URI permission as a document source after the handoff.

Within a shared workspace, the statement job and its import-run controls are available only to the person who uploaded it. Before receiving the file, Modo Próspera records the canonical IDs and a digest of that person's active PRIVATE accounts that are currently eligible for import. A later import may select one or more accounts only from that set, and access is checked again before the normalized history is created or first published. For abuse limits, Modo Próspera records opaque user/workspace references, time windows, accepted attempts, and the number of body bytes actually received; those counters do not contain statement values or preview cells.

Before parsing, on both paths, a worker performs structural, data-only checks and rejects active workbook content, unsafe archive structures, formulas, external links, and files outside fixed resource limits. The transient closed-test worker runs in a restricted Linux sandbox with network and process creation denied. The durable annual-history path additionally runs a signature-based ClamAV check against a pinned signature snapshot inside the isolated worker described below; a file the scanner reports as infected is rejected, and so is a file the scanner could not examine because it was unavailable.

None of this is antivirus clearance. A result that is not "infected" does not mean a file is safe, no result here makes opening an untrusted statement zero-risk, and Modo Próspera does not tell you that your file was scanned clean. Strict checks can also reject a legitimate bank export.

The universal mapper can return a small, bounded structural preview to the authenticated uploader. That preview is not retained and is never used as a telemetry payload. If you confirm an import or mapping, normalized annual-history evidence, staged rows, and versioned mapping templates are retained as product data as described below. They are not another copy of the original CSV, XLSX, OFX, QFX, or supported exact-layout PDF/HTML-as-XLS bytes. Neither this closed-test path nor the durable custody described next creates a bank/provider API connection.

Durable Encrypted Custody For Annual-History Imports

When you stage an annual-history import, the Android app sends the file once over TLS to Modo Próspera, never directly to Google Cloud Storage. Modo Próspera then encrypts it with a fresh random per-file AES-256-GCM key, wraps that key with Google Cloud KMS, and writes only the ciphertext to a private, versioned Google Cloud Storage bucket in us-east4 that uses customer-managed encryption keys. The storage object name is a random opaque value: it contains no filename, workspace, user, institution, media type, account, date, or content digest. PostgreSQL holds only bounded metadata, the wrapped key material needed while the file is still usable, safe structural manifests, and cleanup evidence — never the encrypted or the plaintext statement.

Native V28 Client-Framed Upload

The legacy v27 resumable upload transport remains disabled. Native v28 client-framed upload is enabled for the governed Closed-test flow. When you choose that resumable flow, Modo Próspera may hold a separate temporary AES-256-GCM encrypted recovery object plus bounded chunk and cleanup evidence. That object is never a parser source, is scheduled for verified deletion before 6 days and 23 hours, and is deleted sooner on completion, cancellation, expiry, authority loss, or user/workspace deletion. Its terminal receipt contains no statement bytes or reusable credential and is retained for at most 30 days after activation, cancellation, or expiry.

Parsing then happens outside the app's own service, in an isolated worker container on a separate Google Compute Engine host in the same region, with no network access, its own identity, a read-only root filesystem, bounded writable scratch, dropped capabilities, and platform CPU, memory, and process limits. The worker reads exactly one authenticated encrypted file, and returns only a bounded structural report — format, encoding, aggregate row/cell/sheet counts, aggregate outcome counts, and the malware-policy status. It never returns row values, headers, filenames, descriptions, counterparties, balances, or account identifiers. Because the parse runs after your upload finishes rather than during it, staging is asynchronous: the import appears as queued and its result arrives when the isolated worker completes.

Any of cancellation, expiry, account or workspace deletion, stale authority, a tampered or unauthenticated file, an ambiguous storage response, or unverified absence fails closed and leaves cleanup pending rather than publishing financial data.

How long the encrypted statement is kept. The first deletion deadline set when the file is admitted cannot be extended, including by a retry. A later event can only shorten the remaining lifetime. The deadlines are:

  • It is waiting for you to finish mapping or act. Deleted 7 days from admission.
  • The import published successfully. Deleted within 24 hours after publication.
  • It failed, was cancelled or rejected, or was password-protected. Deleted within 24 hours of that outcome.
  • A retry superseded it. Deleted within 24 hours, or sooner when it is no longer needed for recovery.
  • You deleted your account or the workspace. Access is revoked and cleanup is requested immediately.

In no case is the encrypted statement kept beyond 30 days.

How deletion is proven. Deleting the encrypted statement is cross-system work, not a flag in our database. Modo Próspera first revokes further use of the file, crypto-erases its wrapped key so the ciphertext can no longer be decrypted, and records an immutable cleanup obligation naming the exact stored version. That obligation survives deletion of your account records. A cleanup processor then deletes the exact version in storage and afterwards verifies that the object, every version of it, and any incomplete upload of it are absent. A delete response or a delete marker on its own is not accepted as proof. If absence cannot be verified, the record stays pending and cleanup keeps retrying; the deadline is never treated as proof that deletion happened.

The completion proof retains only opaque or digested storage-locator and version evidence, the statement-content fingerprint, the reason, the request, crypto-erasure and verification times, the verification method and version, the attempt number, the aggregate safe manifest identity, and a proof digest. It retains no storage locator, wrapped key, nonce, ciphertext, plaintext, filename, statement row, or financial value.

Deleting the raw statement does not delete what you asked Modo Próspera to keep: normalized annual-history evidence, staged rows, publication evidence, and confirmed mapping templates follow the ordinary retention and deletion rules described under Retention.

For bank-format validation, Modo Próspera accepts a tester sample only with the tester's explicit consent and through the restricted evidence flow, not from publicly posted customer statements, email, analytics, logs, or Git. Any example kept in the repository must be synthetic and replace every name, account/reference, amount, date, balance, and description after privacy review. The controlled Produbanco XLSX/digital-PDF and Pichincha digital-PDF/passive HTML-as-XLS layout validation completed on July 31, 2026; no raw statement or derived customer content was retained in Git or durable fixtures. Bank selection by itself is still not proof of a statement format.

Do not send bank statements, passwords, session tokens, or full account exports by email.

Format-Support Diagnostic

The protected Android release does not offer or send a format-support diagnostic. Prepared backend controls remain disabled because the app cannot yet review every required structural classification locally before consent. No current support route admits an original statement or reconstructed specimen. A future release would require a new reviewed disclosure and an exact, user-visible metadata preview before activation.

Optional Demand Telemetry

Statement-format demand telemetry is optional and off by default. Modo Próspera records it only after you accept the current consent version. Declining or withdrawing does not block preview, mapping, template, or import features.

The telemetry contract accepts only an exact allowlist: bounded country and institution references, a format category, a keyed HMAC fingerprint derived from the normalized schema, a mapper outcome, and bucketed issue counts. It does not contain filenames, raw or normalized headers, rows, values, descriptions, financial account data or identifiers, statement content digests, or installed-app inventory. Android checks an exact allowlisted bank package and its signing certificate locally when offering a bank-app launch; it does not enumerate or report the user's installed apps.

Unaggregated opt-in events are retained for no more than 90 days. Operator aggregates are created only for groups representing at least five distinct workspaces (k >= 5) and are retained for no more than 13 months. Withdrawing consent deletes that user's unaggregated events; an already-created thresholded aggregate remains until its 13-month expiry. The account export includes the requester's consent state and unaggregated events plus workspace mapping templates.

Product Measurement

Modo Próspera derives coarse product measures from functional evidence already needed to operate trustworthy closes: bucketed time to the first close, bucketed review/correction/coverage burden, whether a close was reopened or superseded, and whether the immediately following second and third cycles were completed. It can also retain a structured support-effort record containing only an allowlisted category and channel, an optional close ordinal, a guided-intervention flag, and a minutes bucket. It does not add an analytics SDK or record screen surveillance.

The measurement contract cannot represent transactions, amounts, merchants, beneficiaries, descriptions, statement content, filenames, paths, account numbers, row identifiers, names, emails, free text, or content digests. Exact functional timestamps remain in the operational record; released measurement uses coarse elapsed/count buckets. Published cohorts require at least five distinct workspaces. A smaller cohort is suppressed without revealing its size, and workspace references never leave the aggregate.

Willingness-to-pay research is a separate, default-off purpose. A response is accepted only after current product-research-consent-v1 consent and contains only offer, cadence, explicitly selected ISO currency, price bucket, intent, preferred-value category, and experiment version. It contains no free text. Declining or withdrawing does not change import, review, closing, account export, deletion, or any other product access. Withdrawal deletes the unaggregated WTP response.

Unaggregated WTP and support-effort records expire within 90 days. The current operator endpoint computes the thresholded aggregate on demand and does not store an aggregate snapshot; any separately approved retained snapshot would expire within 13 months. Account export includes the workspace's current consent and unaggregated records; workspace/account deletion removes them. The Play tester eligibility ledger is separate and is never joined to these product measures.

Google Sheets Export

Google Sheets sync/archive is optional. If it is enabled for your household, Modo Próspera writes approved month-close data to the configured Google Sheet. Google credentials are kept on the backend and are not sent to the Android app.

Google Sheets exports are separate user or household export destinations. Deleting household data in Modo Próspera removes the app's stored household data, but it does not delete a Google Sheet copy that you control. Delete or unshare that Sheet separately if you no longer want to keep it.

Retention

Modo Próspera keeps month-close receipts, normalized closed transactions, normalized annual-history evidence, staged rows, versioned mapping templates, account/cycle-bound promotion snapshots, explicit account-currency evidence, feedback, household metadata, audit events, and the durable parsed compatibility/data-quality evidence described above until the applicable account/workspace deletion. Beta feedback you wrote in a workspace is deleted earlier when you delete your account, including from a household you previously left or were removed from. A standalone leave or owner removal keeps that feedback until one of those deletion events; it does not extend the person's access to the household. Operational rollback can deactivate retained product evidence without erasing it, and routine time-based cleanup does not prune it.

Unclosed import previews and closed-import retry payloads are pruned after short configured retention windows. Expired or revoked sessions, invitations, and auth replay-protection records are pruned by maintenance cleanup.

Unaggregated willingness-to-pay and structured support-effort records expire within 90 days. Current research consent and unexpired raw records are included in account export and removed by workspace/account deletion. Released product-measurement cohorts contain no workspace reference and require at least five distinct workspaces. The current response is computed on demand rather than stored; any separately approved retained snapshot would expire within 13 months.

After deletion, Modo Próspera removes the workspace's durable parsed financial and model evidence and keeps a minimal deletion marker containing the workspace/household ID and the deletion timestamp. It does not contain financial records, members, feedback, sessions, invitations, or setup data. This marker is retained to prevent the deleted workspace ID from being recreated and reconnecting data that should remain deleted. If local cleanup cannot finish immediately, a minimal operator retry record remains only until cleanup succeeds. If a provider cleanup obligation had already been recorded, its digested obligation and attempt evidence — workspace/connection identities, consent/principal references, route/institution references, digested references, and lifecycle/proof records, with no raw provider credentials or tokens — is retained indefinitely as security and audit evidence, even after that cleanup completes. No production provider connections exist in the current beta, so such records cannot yet arise from real user activity.

Completed account deletion also leaves permanent, privacy-minimized lifecycle history under a SHA-256 digest of the app user ID, not the raw user ID or Google account. Each entry contains only a deletion-operation digest, completion timestamp, hash-linked current and prior generation values, and a digest of the completion receipt. It contains no workspace IDs, financial or profile data, membership lists, action lists, counts, cleanup outcomes, or receipt contents. This history prevents a paused pre-deletion request from recreating the account and lets the backend require a verified reauthentication completed after the latest deletion. Activated role and ownership-transfer controls retain the privacy-minimized, generation-bound security/audit records needed to prove the transition and reject stale requests. They do not create a multi-party deletion consent or transfer financial-account authority.

The encrypted statement held in durable custody for an annual-history import is retained under the deadlines in Durable Encrypted Custody For Annual-History Imports: seven days while it waits for mapping or another action from you, within 24 hours after publication or a terminal failure, rejection, cancellation, or superseding retry, immediately on account or workspace deletion, and never beyond 30 days. If storage cleanup cannot be verified, access and publication remain fenced and cleanup keeps retrying rather than treating the deadline as proof of deletion. Its PostgreSQL control records contain bounded admission, authority, storage-version, verification, and cleanup state. Wrapped keys and nonces are crypto-erased when the file is revoked. The terminal upload receipt, including its content fingerprint, bounded size/type, opaque identities, storage-version observations, and cleanup/absence digests, is retained for at most 30 days after activation, cancellation, or expiry and is then pruned only after fail-closed consistency checks. Cancelled/expired receipts remove direct workspace/user IDs immediately; governed cleanup can continue using their digested authority.

Account Deletion

You can delete your entire Modo Próspera account:

  • In the app: Account → Data and privacy → Delete my account. (In Spanish: Cuenta → Datos y privacidad → Eliminar mi cuenta.) The app first shows a per-workspace deletion plan and requires exact confirmation text before anything is deleted.
  • On the web: https://modoprospera.com/eliminar-cuenta/?lang=en describes the same steps and the external request path (email the support contact from the Google account address you use to sign in; requests are verified against your sign-in identity and completed within 15 days, unless a workspace you own is blocked by the member or shared/joint-account conditions below, in which case we tell you what is required).

What happens per workspace:

  • A workspace you own with no other active members is deleted entirely, as described under Export And Deletion.
  • A workspace you own that still has other active members cannot be deleted by full-account deletion in the current protected release. Remove each non-owner member through the household controls and retry. Deletion of a workspace with shared/joint accounts remains unavailable unless a separately reviewed flow is deployed; role management or ownership transfer does not make that flow available.
  • A workspace where you are a member or View-only user is left, not deleted: your access, sessions, and pending invitations for that workspace end, and the beta feedback you wrote there is deleted, but the household's own data (closed months, transactions, audit history) remains with the household.

Household invitation, ownership transfer, and per-account permission controls remain unavailable until their hosted capability is activated and negotiated by the protected client. Source code or database schemas alone do not make a control user-visible. Multi-party deletion consent is not available in this release even when the other household controls are active.

After your workspaces are processed, all your remaining sessions are revoked. If nothing else references your account, the account record itself is deleted. If retained audit evidence in a household you left still references your account — which is always the case after leaving a shared workspace — Modo Próspera keeps a minimal account record as an opaque derived reference: its display name is replaced with the fixed internal placeholder "Cuenta eliminada" — Spanish for "deleted account"; the stored value is the same whatever language you use — and it contains no name or email. A later fresh sign-in with the same Google account can associate that pseudonymous reference with the new account lifecycle generation, but it does not restore deleted profile, membership, workspace, or financial data.

Modo Próspera's backend cannot delete your Google/Firebase sign-in record: after the backend confirms deletion, the app deletes your Firebase Authentication user from the device, asking you to sign in again first if Firebase requires a recent login. If that final step fails, the app signs you out, and you can also remove Modo Próspera's access from your Google account settings. For deletion requests made by email, the operator deletes the Firebase Authentication record manually from the Firebase console as part of fulfillment.

Deleting your account does not permanently block the same Google account from signing in later. A later sign-in is accepted only from verified Firebase authentication whose authentication time is after the latest completed deletion. It creates a new account lifecycle generation and a distinct default workspace. The old workspace tombstone is never cleared or reused, and the new generation does not restore the deleted account's profile, memberships, workspaces, or financial data. The permanent privacy-minimized lifecycle history described under Retention enforces that boundary.

Export And Deletion

An eligible effective owner can request an access-filtered export of the active workspace in the app, including its setup/domain data and eligible parsed compatibility/data-quality evidence, normalized annual-history data, versioned mapping templates, and the requester's unaggregated opt-in telemetry without raw tokens, original statement bytes, or sibling-workspace records. A separate cash-ledger export is available to any signed-in person with current export permission for a cash account. It is limited to that person's export-visible cash movements, append-only revisions, and period seals; owner status does not bypass a private holder's account boundary. A member or View-only user does not receive the in-app full-workspace export and can ask the support contact for a verified access copy of other personal data and records we may lawfully disclose to them. Household/business owners can delete the active workspace after exact confirmation. Deletion removes that workspace's setup/domain, account, invitation, feedback, import, month-close, transaction, and audit data while also removing its normalized annual-history evidence, mapping templates, telemetry consents, and unaggregated telemetry events, while preserving other workspaces. Already-created k >= 5 telemetry aggregates age out under the 13-month limit rather than becoming user-level export records. Signed-in users can also delete their entire account, as described under Account Deletion. A member or View-only user can instead leave a household through the standalone leave action, and an effective owner can remove a non-owner member. Either action revokes the affected person's household access and active household sessions, and removes that person's optional unaggregated statement-format telemetry and consent, closed-test statement enrollment, and authored mapping-template lineages, without deleting the household's own closed months, transactions, or audit history. It keeps that person's earlier feedback until the household is deleted or the feedback author deletes their entire account.

The records intentionally retained permanently after deletion are:

  • the minimal deletion tombstone (workspace/household ID and deletion timestamp) described above;
  • already-recorded provider cleanup obligation/attempt evidence, retained indefinitely as security and audit evidence as described under Retention;
  • the privacy-minimized account-lifecycle history described under Retention, retained to fence old requests and prove the boundary between completed deletion and a later new account generation;
  • if an encrypted statement artifact ever existed for the workspace, the minimal external-artifact cleanup record: the cleanup obligation, its attempt history, and the verified-absence proof, containing only opaque or digested storage-locator and safe-manifest identities, reasons, states, and timestamps — never a filename, key material, encrypted or plaintext content, or statement values. An annual-history import creates such a record, and it survives the deletion of the workspace it came from so that the pending external deletion can still be finished and proven; and
  • the minimal opaque account reference kept when retained audit evidence in another household still references a deleted account, with its display name replaced by "Cuenta eliminada".

Temporary cleanup records are consumed when their work is complete.

Deleted household data may remain recoverable for a short period inside the hosted database provider's backup or restore window. If Modo Próspera ever restores the database from backup after a deletion request, we will reapply affected deletion requests before returning the service to beta users.

Security

Modo Próspera stores session token verifiers rather than raw session tokens for new sessions. Android sends a stable installation fingerprint so the backend can reject a copied session token used from a different app installation. Firebase App Check may be used to verify that requests come from the real Android app.

Firebase Authentication collects IP addresses and user-agent details with sign-in requests as part of its security and abuse-prevention purpose; Google retains that logged data for a few weeks. Our hosting providers also keep short-lived infrastructure request logs that include IP addresses. Modo Próspera does not use IP addresses to infer or collect your location.

Service Providers

The hosted beta may use Firebase for sign-in and app attestation, Render for backend hosting, Neon for PostgreSQL storage, GitHub Actions for maintenance/ build automation, Google Sheets for optional exports, and Cloudflare for hosting and protecting the public modoprospera.com site. That site carries no account data; a visit reaches Cloudflare's edge, which sees the ordinary request metadata any web host receives. While we compare two visual versions of the marketing site, Cloudflare may set one first-party, host-only cookie so your assigned version remains stable within one fixed experiment window for up to 30 days. The signed cookie contains a random assignment nonce and the limited experiment state needed to keep that assignment stable. It contains no account identifier or financial data, is not used for cross-site tracking or advertising, and does not provide the website with access to app data. To prevent the same valid assignment from recording the support-page outcome twice through concurrent or replayed requests, Cloudflare also holds a short-lived atomic claim addressed only by a one-way cryptographic digest of the random assignment nonce and fixed experiment population. The claim stores only a converted bit and the fixed experiment-expiry time. It becomes logically invalid at that time and is removed lazily on a later claim; deletion is also scheduled for expiry, although Cloudflare retries may delay physical removal. It does not store the raw nonce or cookie, assigned version, URL, referrer, IP address, user agent, locale, account identifier, app data, or financial data.

Google Cloud is also a statement-data service provider. Google Cloud Storage holds the encrypted statements described under Durable Encrypted Custody For Annual-History Imports, Google Cloud KMS holds the keys that wrap their encryption keys, and a Google Compute Engine host in us-east4 runs the isolated parser worker. Google Cloud receives the encrypted statement, not a readable one; the keys that could decrypt it are held under Cloud KMS and are crypto-erased when the file is revoked.

These providers may process data outside Ecuador, including in the United States, where the hosted beta and the us-east4 custody and parser infrastructure run. Any such processing is limited to operating the services described in this policy. A new provider or region must be reviewed and this policy updated before it receives Modo Próspera user data.

Contact

For privacy questions, export/deletion help, or beta support, use the support contact shown at https://modoprospera.com/soporte/?lang=en.

Changes To This Policy

This policy may change as the beta evolves. We update this page when the product or hosted infrastructure changes materially, and the revision date at the top identifies the version you are reading. A change that materially widens how personal data is used takes effect only once it is published here, and where the change concerns a feature that runs on your consent, the app asks for that consent again rather than relying on the earlier one.