Privacy Policy

Publication note

This Privacy Policy identifies the GeriPay service as being operated by Vedat Ellidokuzoglu, an individual sole proprietor based in Illinois, United States. Privacy, rights-request, support, and general legal-material questions may be directed to privacy@geripay.com.

Section 1. Introduction and Privacy Framework

1.1 What this Privacy Policy is and what it is for

This Privacy Policy describes how GeriPay processes information in connection with the Service. In this Privacy Policy, "GeriPay," "we," "us," and "our" refer to Vedat Ellidokuzoglu, an individual sole proprietor operating the Service under the GeriPay brand from Illinois, United States. It is a disclosure document about how information is collected, created, used, shared, stored, protected, and retained across the product's real operating environments. It is not a promise that every information practice will remain static forever, a warranty of perfect confidentiality or perfect deletion, or a guarantee that every privacy-related outcome will be uniform across every context, provider, or jurisdiction.

1.2 What this Privacy Policy is designed to explain

This Privacy Policy is designed to explain the main information categories connected to GeriPay, the service contexts in which those categories appear, the difference between organization-managed use and GeriPay-controlled operational processing, the main purposes for which information is processed, the types of recipients and providers involved, the realities of retention and preservation, and the ways privacy rights may be handled. Later sections go deeper on those topics, but this opening block is meant to make the structure of the product and the structure of the data picture understandable before the lifecycle sections begin.

1.3 Relationship between this Privacy Policy and the Service architecture

GeriPay is not only a static public website. It includes public pages, legal-document pages, account-entry and invite flows, authenticated member and admin workspaces, receipt-upload and SmartScan flows, reimbursement and payout-method workflows, payment-history views, report-generation tools, code-based and public or semi-public verification surfaces, support interactions, legal-acceptance evidence systems, telemetry and monitoring layers, and provider-supported hosting, storage, communications, and processing infrastructure. This Privacy Policy should be read with that multi-surface architecture in mind.

1.4 Relationship between this Privacy Policy and organization-managed use

Much of the Service is used by organizations and their authorized users inside organization-managed workspaces. That means some information handling is shaped by the organization's decisions about who is invited, who has access, what gets reviewed, how reimbursement workflows operate, and what internal visibility exists. At the same time, GeriPay separately controls platform functions such as authentication, session protection, provider management, support, fraud review, auditability, incident handling, legal response, and defense of the Service. This Privacy Policy reflects both layers.

1.5 How this Privacy Policy should be read

This Privacy Policy should be read as an operationally realistic map rather than as a set of isolated labels. The same record can appear in more than one section because the same receipt, account record, verification artifact, support message, or technical log may be used for more than one purpose, may be visible to more than one audience, and may persist for more than one reason. Short user-interface labels, workflow states, or product names do not by themselves fully describe the privacy implications of a record.

1.6 Interpretive cautions and disclosure limits

One record may move across ordinary workflow use, support handling, fraud review, provider-supported processing, incident analysis, retention systems, archival copies, or dispute preservation without changing its basic identity. Internal workspace visibility is not the same thing as public availability. Deletion of a visible record is not always the same thing as deletion from backups, preserved evidence, or provider-linked systems. This Privacy Policy is intended to describe those realities candidly rather than to hide them behind overly simple phrasing.

Section 2. Scope of Coverage and Service Contexts

2.1 Covered service surfaces and product family scope

This Privacy Policy applies to GeriPay's websites, applications, hosted product features, authenticated and unauthenticated service surfaces, support interactions, operational and security review environments, and related service-management contexts that are part of the Service. It is intended to cover current and future versions of those surfaces, including renamed, reorganized, expanded, or successor features, so long as they remain part of the same overall product family and associated operating environment.

2.2 Public website, legal-page, and informational contexts

This Privacy Policy covers visits to public pages, informational pages, legal pages, and other unauthenticated surfaces associated with the Service. Even when a visitor does not create an account or enter a workspace, those visits can still generate request records, browser and device context, IP-related information, provider-supported delivery events, error and performance signals, and security or abuse-monitoring signals. Public browsing is therefore part of the Privacy Policy's scope, even though it differs from authenticated workspace use.

2.3 Account-entry, onboarding, and access-recovery contexts

This Privacy Policy also covers signup, invite issuance, invite acceptance, login, email verification, password reset, account recovery, email-change confirmation, legal-acceptance flows, and other account-entry or re-entry paths. These flows often create identity records, access records, verification records, and assent-related evidence before ordinary workspace activity even begins. For that reason, the privacy picture starts before a person becomes an active user inside a workspace.

2.4 Authenticated workspace contexts

The core operational context of the Service is the authenticated workspace environment used by members, admins, and other authorized users. That environment may include receipt uploads, draft and saved receipt records, SmartScan processing and review, reimbursement creation and review, payout-method management, payment-history views, report generation, workspace administration, member-management activity, and related workflow history. The fact that these functions occur inside a workspace does not mean they are processed only for the immediate user-facing workflow.

2.5 Public verification and code-based access contexts

Some GeriPay-generated artifacts may be viewed through verification codes, outward-facing verification pages, linked previews, or similar access-enabling references that work outside ordinary workspace authentication. These code-based and public or semi-public verification contexts are treated separately in this Privacy Policy because they create different visibility, logging, monitoring, and downstream-sharing consequences than private workspace views.

2.6 Support, security, fraud, audit, legal-response, and provider-supported contexts

Information may also be processed in support, troubleshooting, diagnostics, reliability review, fraud and abuse review, security monitoring, incident response, auditability, evidence preservation, legal response, insurance matters, and provider-management contexts. Those contexts may involve review of information that originally entered the Service through a different surface, such as a public page, a login flow, a receipt upload, a reimbursement workflow, or a report-verification event.

2.7 Context overlap, transitions, and scope boundaries

The same information can move across contexts. A receipt may begin as a private upload, become part of SmartScan processing, feed a reimbursement request, appear in a report, contribute to a verification-linked artifact, and later be reviewed for support, fraud, audit, or dispute purposes. At the same time, this Privacy Policy does not claim to cover systems not operated by GeriPay, purely internal organization conduct outside the Service, or downstream third-party environments once others independently copy or redistribute records outside GeriPay's controlled surfaces.

2.8 Information-origin and entry-path overview

Information in GeriPay does not enter the Service through only one path. Some information is provided directly by users, such as account details, uploaded receipt images, reimbursement explanations, payout-method submissions, support messages, or legal-acceptance inputs. Some is created or supplied by organizations, admins, or other authorized workspace participants, such as invites, role assignments, workspace-governance actions, internal review decisions, admin corrections, report-generation events, and organization-managed visibility or routing choices. Some is collected automatically through browser, device, session, request, public-verification, communications-delivery, logging, monitoring, security, and provider-supported operational layers. Some is derived by the Service through SmartScan, OCR, normalization, structuring, traceability, analytics, fraud review, verification linkage, or other automated or evidence-supporting processes. This source diversity matters because later sections of this Privacy Policy describe not only what data exists, but also why the same record family can include direct submissions, organization-generated context, automatically collected telemetry, and derived operational artifacts at the same time.

Section 3. Role Framing: Organization-Directed Processing Versus GeriPay-Controlled Processing

3.1 Why the role-framing section exists

Role framing is one of the organizing principles of this Privacy Policy. GeriPay is used by organizations and their authorized users, but GeriPay also independently operates, secures, supports, audits, and defends the platform. As a result, some privacy questions are driven mainly by the organization's decisions inside its workspace, some are driven mainly by GeriPay's own operational and legal obligations, and some involve both. This section is intended to make that mixed structure clear before later sections discuss rights, disclosures, providers, and retention. It is a disclosure and request-routing framework, not a restatement of every responsibility-allocation, disclaimer, liability, or dispute rule that appears in the Terms of Service.

3.2 Organization-directed processing and workspace-governed decisions

Organizations may decide who is invited, who is given admin or member access, what users are permitted to upload into the workspace, which records are reviewed or corrected internally, how reimbursement workflows are configured, what internal approval or visibility rules apply, how generated reports, exports, verified PDFs, or verification-enabled artifacts are used or shared, and in some cases how long workspace materials remain visible or retained within the organization's own business processes. In that sense, certain handling of workspace records is organization-directed. GeriPay provides the platform for those activities, but GeriPay is not ordinarily the internal approver, finance department, payroll department, or internal policy authority making those underlying organizational decisions. At the same time, organization-directed control does not eliminate GeriPay's separate ability to retain related records for authentication, support, security, provider management, incident response, auditability, or legal preservation where those independent Service needs apply.

3.3 GeriPay-controlled processing and platform-operation decisions

GeriPay separately controls platform operations such as identity and session management, provider selection and infrastructure management, support and troubleshooting, quality review, security monitoring, fraud and abuse detection, audit and evidence preservation, incident response, legal response, and defense of the Service. Those functions may involve reviewing account records, workspace records, uploaded materials, reports, verification events, support messages, or telemetry even though the ordinary business workflow happens inside an organization-managed workspace.

3.4 Same information processed in both contexts

The same information may be processed in both organization-directed and GeriPay-controlled contexts. A receipt may be uploaded for an organization's reimbursement workflow, then reviewed by GeriPay personnel to troubleshoot a SmartScan problem or investigate suspicious activity. A report may be created for internal business use, then later examined in a dispute or verification-abuse review. An account or membership record may be used to manage workspace access and also to confirm identity, detect compromise, or preserve evidence. Role allocation therefore depends on processing context and purpose, not only on data type.

3.5 Request routing and rights-handling logic

Because of this mixed model, some requests about information may need to be directed first to the organization that manages the workspace, some may be handled directly by GeriPay, and some may require coordination between both. The correct path may depend on whose records are involved, who controls the relevant workflow decision, whether the information is part of ordinary workspace use or GeriPay's own operational records, and whether identity, authority, fraud, security, or legal-preservation concerns affect the request.

3.6 Jurisdiction-flexible role language and drafting restraint

Different privacy laws may use different labels for these relationships, including controller, processor, business, service provider, and similar concepts. This opening section is intended to preserve room for those jurisdiction-specific distinctions without oversimplifying the entire policy into one globally uniform label. Later rights and jurisdiction sections may apply narrower legal framing where required, but the practical point remains the same: some processing is organization-directed, some is GeriPay-controlled, and some is mixed.

Section 4. Categories of Individuals and Relationship Types Covered

4.1 Organization customers, admins, members, and invitees

The information described in this policy may relate to organization customers, account creators, admins, members, invitees, onboarding-stage users, deactivated users, removed users, suspended users, and former workspace participants whose records remain associated with the Service. The fact that a person no longer has active access does not necessarily mean the Service no longer processes information about that person in support, audit, security, fraud, retention, or legal contexts.

4.2 People described in workflow records and supporting materials

Information in the Service may also relate to people other than the direct account holder or currently logged-in user. Receipt images and workflow records may refer to merchants, payees, beneficiaries, employees, contractors, recipients, approvers, support contacts, or other individuals named, visible, or implied in uploaded materials, reimbursement records, payout-method metadata, reports, comments, attachments, or preserved evidence. This policy therefore is not limited to information about active account holders alone.

4.3 Public visitors, verification viewers, and unauthenticated requestors

The Service may also process information about public-site visitors, viewers of legal pages, verification-code holders, viewers of the public verification page or other public or semi-public verification surfaces, prospective users, support requestors, and other unauthenticated persons interacting with GeriPay surfaces. Those individuals may generate browser, device, request, and access-event records even if they never create a full account or enter an authenticated workspace.

Section 5. Account, Identity, and Profile Information

5.1 Core identity, name, and contact records

We process names, profile-facing identity fields, typed-name values associated with legal-acceptance or verification events, login email addresses, current account email addresses, prior-contact history where relevant, and other account-identity or contact details used to create and maintain user identities within the Service. In GeriPay, these records do more than support profile display. They are part of authentication, delivery of notices, invite acceptance, reimbursement and report attribution, support verification, account recovery, legal-acceptance evidence, security review, and later dispute handling. For that reason, identity and contact records should not be understood as a thin profile layer detached from the rest of the product.

5.2 Account identifiers, organization affiliation, and structural linkage

Accounts may be linked to internal user identifiers, organization and workspace identifiers, membership records, role records, invite records, settings, support records, legal-acceptance evidence, reimbursement activity, payout-method activity, payment-history activity, report activity, verification artifacts, and other structural parts of the product. These links are part of ordinary Service architecture in an organization-scoped multi-user product. They help determine what information belongs to which person, which workspace, which workflow event, and which historical state, and they may remain important even when visible profile fields, current access status, or current workspace affiliation later change.

5.3 Credential, verification, recovery, and change-state records

We process credential-related records, password-hash or equivalent verification material, email-verification state, password-reset and recovery events, challenge or code-confirmation events, email-change confirmation events, and related account-integrity records. These records are not one-time disposable events. They can become part of support history, fraud review, account-compromise analysis, legal review, or later evidence about how access was created, verified, recovered, changed, or restored. In a product like GeriPay, where account access can expose receipts, reimbursement workflows, payout-method information, and report artifacts, verification and recovery history is itself a meaningful category of personal information.

5.4 Invite, onboarding, and account-entry lifecycle records

Account data may also include invite issuance and intended-recipient context, signup-stage records, invite acceptance completion state, onboarding milestones, workspace-entry history, and records showing whether a person never completed entry, completed entry and later lost access, or re-entered after an access or credential event. This is operationally important because GeriPay frequently ties account creation to organization membership rather than to a purely standalone consumer signup flow. As a result, the account record often includes both identity data and evidence about how the person first entered the workspace, under whose authority, and at what point the account became usable.

5.5 Profile settings, presentation records, and account-facing preferences

We may also process profile-facing settings and account-linked presentation records, such as notification preferences, avatar records where provided, profile customization records, localization or similar presentation settings, and service-interaction records linked to the account. These records are generally less sensitive than some workflow records, but they still may affect how the Service functions, how notices are delivered, how support recognizes an account, and how account activity is interpreted later. Even seemingly minor account settings can matter when GeriPay needs to reconstruct what a user saw, what message path was used, or which account identity was associated with a later workflow or dispute.

5.6 Account-linked support, ownership-verification, and service-interaction history

When users ask for help with login problems, invite issues, verification problems, reimbursement visibility, report access, payout-method changes, or other account-linked matters, we may process support requests, explanatory messages, screenshots, attachments, case notes, ownership-verification steps, and records showing what account or workspace data was reviewed to resolve the issue. These support-side records may later be reused if the same issue reappears, if access is contested, or if fraud, incident, or legal review becomes necessary. For that reason, account-related support records are part of the long-tail account data picture, not merely transient customer-service chatter.

5.7 Account-linked security, fraud, and lifecycle evidence

Account-linked records may also include suspicious-login indicators, sign-in anomalies, session-risk signals, support-ownership verification records, deactivation or reactivation history, removal history, legal-acceptance linkage, dispute markers, impersonation or account-takeover allegations, and other long-tail account evidence. These records may continue to matter after ordinary workspace use ends because they help explain access history, support later review, and preserve a reliable operational chronology. In a role-based workspace, records showing when an account's authority changed can be as important as the account's visible identity fields.

5.8 Post-access persistence and residual account-linked records

Even after a user stops using a workspace or loses active access, GeriPay may continue to process residual account-linked metadata, historical contact and verification records, support history, session history, legal-acceptance linkage, reimbursement or report attribution, and preserved security or dispute records. This does not mean every account record remains equally active forever, but it does mean that account data in GeriPay should not be understood as disappearing the moment a visible profile or current membership changes. Historical account records may remain linked to reimbursement decisions, payment-history entries, report artifacts, verification events, fraud reviews, or legal-preservation needs.

Section 6. Organization, Workspace, Role, and Membership Information

6.1 Organization identity, tenancy, and workspace-structure records

We process organization names, workspace identifiers, tenant linkage, country or service-configuration context, administrative ownership context, and other records that define the organization-managed environment in which the Service operates. These records help explain that GeriPay is a multi-user, organization-facing product rather than a purely personal-use application, and they shape how records are grouped, displayed, routed, and reviewed across many other sections of this policy. In practice, workspace structure affects who can upload receipts, who can review reimbursements, who can manage payout-related settings, who can generate reports, and who can later revisit those records in support, security, or dispute contexts.

6.2 Membership lifecycle, invite history, and user-to-workspace relationship records

We process membership-creation records, invite issuance records, invite-delivery and acceptance history, expiration or revocation state, role-assignment chronology, deactivation or removal history, and other records showing how a person entered, used, changed position within, or lost access to a workspace. Membership history often remains relevant after a user's current role changes because it can affect support, auditability, security analysis, fraud review, and dispute response. In GeriPay, the question of who was part of a workspace at a given time can also matter when interpreting reimbursement submissions, payout-method changes, payment-history visibility, report generation, or later arguments about authority.

6.3 Roles, permissions, internal visibility, and authority context

We process records about current and historical role assignments, permission scope, admin status, internal visibility rules, authority context, and other access-boundary information that determines what a person can see or do inside the Service. These records matter not only for current product behavior, but also for later analysis of whether an action occurred under admin authority, member authority, stale authority, delegated authority, or inappropriate visibility conditions. Because GeriPay is not a flat single-user application, role and permission data is one of the main categories that explains why a given user could access receipts, reimbursements, payout methods, payment history, reports, or member-management tools at a particular point in time.

6.4 Workspace governance, admin activity, and management history

Workspace administration can create its own records, including management actions, member invites, deactivations, reactivations, removals, role changes, review routing, administrative edits, internal governance decisions, and related audit history. Those records may be important for ordinary organization-managed workflow use, but they may also be revisited in support, fraud review, security response, audit, employment disputes, or legal-process contexts. Admin-side actions may also affect what reimbursements are reviewed, what saved receipts are corrected, what reports are generated, and which members are still authorized to participate in the workspace.

6.5 Workflow configuration, routing, and workspace-level operational context

Workspace data may also include records about how the organization uses GeriPay operationally, such as review-routing context, member-versus-admin workflow boundaries, organization-scoped reporting context, and other settings or structural choices that shape how reimbursements, payout handling, and reports move through the Service. Even when these records are not all displayed as editable settings in one screen, they may still exist as stored state or audit context that helps explain how an item entered review, who could see it, why it was routed a certain way, or why an output was generated under a particular organizational scope.

6.6 Workspace-linked support, fraud, security, and legal contexts

Workspace and membership records are often reused in support, troubleshooting, anomaly review, fraud analysis, incident investigation, audit, legal response, and preservation settings. For that reason, workspace data should not be understood as existing only while a user is actively browsing the workspace. These records may persist across backups, preserved evidence sets, dispute files, or provider-supported operational systems even when a person's active access has changed. A workspace-level issue may require GeriPay to review who invited whom, who changed a role, who deactivated access, which admin performed a correction, or which member originally submitted a reimbursement-linked receipt.

6.7 Post-membership persistence and cross-record linkage

Loss of active workspace access does not necessarily sever the historical relationship between a person and workspace data. Membership and role records may remain linked to saved receipts, SmartScan correction history, reimbursement workflows, payout-method changes, payment-history events, report-generation history, verification artifacts, support tickets, and preserved audit trails. This is one reason the workspace-data category is broader than a live member list. It can include continuing evidence about past participation, authority, and internal visibility even after the visible workspace roster has changed.

Section 7. Receipt Images, Source Materials, and Upload Data

7.1 Source-upload, draft-entry, and intake records

We process uploaded receipt images and other source materials, including original files, repeated uploads, replacement uploads, multi-file submissions, user-supplied notes, ingestion timestamps, uploader identity, upload state, file format context, file identifiers, and draft linkage created when those materials enter the Service. In GeriPay's current workflow, receipt uploads commonly begin as draft receipts before later review and save steps, so the intake layer can include not only the file itself but also records showing which draft the upload belonged to, when SmartScan was later run, and whether the source material was replaced, retried, or carried forward into a finalized record.

7.2 Ingestion metadata, validation context, and upload-event chronology

Receipt-upload data may also include technical and operational metadata recorded when the source material enters the Service, such as upload timing, file-type and processing context, draft-creation linkage, validation or conversion state, retrieval-related identifiers, and actor context showing who initiated the upload. These intake records matter because the upload step is not merely a passive file drop. It begins the product's receipt lifecycle and can later become relevant in troubleshooting, fraud review, support, audit, or legal-preservation contexts.

7.3 Derivative images, display copies, normalized files, and storage layers

Uploaded materials may produce more than one operational file or display state. Depending on workflow and infrastructure needs, we may process normalized copies, converted copies, preview or thumbnail versions, storage-layer references, retrieval-linked metadata, signed-access delivery context, and other derivative or support-layer records related to the original upload. Those copies are not wholly unrelated to the original image; they are part of the same underlying upload lifecycle and may create separate retrieval, retention, or access considerations. A user may primarily notice one preview image, while the operational environment may maintain additional linked records needed for storage, later display, support, or preservation.

7.4 Information visible in source materials and why originals are their own data family

Source materials may reveal merchant names, dates, times, subtotals, taxes, tips, totals, line items, payment-related markers, identifiers, reference numbers, notes, handwriting, incidental third-party details, or other sensitive information visible in the image itself. In many cases, the original image contains more information than the later structured receipt summary. Those source-layer details may later feed SmartScan outputs, reimbursement records, reports, verification artifacts, support review, fraud analysis, dispute handling, or preserved evidence sets. For that reason, uploaded receipt images should not be treated as interchangeable with the later extracted fields derived from them.

7.5 Access, retrieval, preview, and signed-delivery context for receipt images

Receipt-image processing may also include records showing how a stored source material or derivative copy was retrieved, previewed, displayed, or linked back into the product. Depending on the context, this can include controlled access or signed-delivery mechanisms, internal workspace display context, support-side review context, and records showing whether a given image remained available for later receipt viewing, admin-side editing, reimbursement review, report generation, or dispute examination. These access and retrieval records matter because a receipt image in GeriPay is both content and an operational artifact with its own access history.

7.6 Upload-linked troubleshooting, fraud analysis, and preservation uses

Receipt-upload data may later be processed to diagnose image-quality problems, upload failures, conversion issues, display problems, suspected duplication, manipulated source materials, or inconsistencies between the original image and later structured data. Source materials may also be preserved or revisited for support, fraud review, incident response, dispute handling, auditability, or legal response. As a result, the receipt-image category is one of the most product-specific and operationally sensitive information categories in GeriPay and may remain important well after the initial upload or review step appears complete.

Section 8. SmartScan, OCR, Extraction Outputs, and Review Corrections

8.1 Automated processing stages and extraction-pipeline records

We process uploaded source materials through SmartScan, OCR, AI-assisted extraction, classification, parsing, normalization, structuring, fallback handling, and related automated or provider-supported processing stages designed to interpret receipt content and build product-usable records. This is not a single passive event. It is a multi-stage pipeline that may generate processing-state records, extraction attempts, failure or exception indicators, and provider-supported handling context before a record reaches later workflow stages. In GeriPay, SmartScan is therefore both a user-facing feature name and a real processing pipeline that can create its own technical and workflow history.

8.2 Extracted fields, structured outputs, and derived receipt data families

That processing may create derived and structured records such as merchant identifiers, transaction dates and times, subtotals, totals, taxes, tips, payment indicators, line-item detail, codes, reference values, categories, identifiers, and other extracted or normalized fields associated with the source material. Depending on the receipt and workflow, structured output may also include grouped or related data families such as tax components, payment-related markers, itemized entries, reference numbers, codes, or other machine-readable fields that help GeriPay build a usable saved receipt record. These outputs are derived from the original uploads and related logic. They should not be understood as freestanding facts detached from the source image, because they remain linked to the source, the processing path, and later review or correction history.

8.3 Relationship between the source image, draft output, and saved receipt record

SmartScan output exists in layers. A source image may be ingested into a draft receipt, processed into structured candidate values, shown back to the user for review, corrected or accepted, and then carried forward into a later saved receipt state. We may process records showing how those layers relate to one another, including source-to-output linkage, draft-versus-final state context, and the relationship between machine-generated values and later stored values. This matters because the privacy picture is not limited to one final receipt snapshot. It includes the source material, the derived intermediate output, and the later saved form of the record.

8.4 Review, correction, override, and acceptance-state records

We process records showing how users or admins review, confirm, correct, override, or finalize extracted receipt information. That can include review-state chronology, correction history, acceptance-state history, finalized-versus-needs-review context, related actor and timestamp context, and records showing whether a receipt was user-accepted, user-corrected, or later corrected in another review context. These review-layer records are an important part of the privacy picture because they show not only what the system generated, but also how the generated content was later handled inside the workflow.

8.5 Confidence signals, exception markers, evidence metadata, and traceability records

SmartScan-related data may also include confidence indicators, exception or low-quality markers, extraction-status history, field-evidence or traceability context, escalation or review markers, and other metadata showing why a receipt was treated as straightforward, uncertain, inconsistent, or in need of additional handling. These records can be important for product operation, support, quality review, fraud analysis, and later disputes because they help explain what the system believed it saw, how reliable that view appeared at the time, and what later human intervention changed.

8.6 Provider-supported AI, OCR, and automated-processing context

Some SmartScan-related processing may involve provider-supported AI, OCR, image interpretation, classification, normalization, or similar automated-processing paths. Depending on the service configuration and operational need, source images, extracted text, structured fields, exception context, or troubleshooting context may move through provider-supported infrastructure or tools that help GeriPay interpret and structure receipt data. This provider-supported layer is distinct from the organization's later use of the resulting record inside its workspace. It also means that SmartScan-related data may exist not only in GeriPay's own application records, but also in linked provider-supported processing and operational environments.

8.7 SmartScan-linked support, fraud, incident, and preservation contexts

SmartScan-related information may also be processed for troubleshooting, quality review, hard-case escalation, anomaly review, fraud analysis, incident response, provider coordination, and later audit or legal preservation. A source image and its extraction outputs may therefore move beyond the immediate receipt-review experience into support, provider, security, and evidentiary environments where they remain relevant even after the visible review step ends. This is especially important in a product where SmartScan output may later affect reimbursement requests, payment history, report generation, or challenges to the integrity of a saved receipt.

Section 9. Reimbursements, Payout Methods, and Payment History Data

9.1 Reimbursement-request creation, selected-record linkage, and workflow-entry data

We process reimbursement-request records including selected receipts, request amounts, currency context, requester identity, workflow timestamps, comments, explanations, and records showing which saved receipts were attached to or associated with the request. In GeriPay, reimbursement records are not isolated payment placeholders. They are linked workflow records that often depend on earlier receipt-upload and SmartScan activity, current workspace authority, and the state of other reimbursement items involving the same saved receipts. These records can therefore include not only the request itself, but also the surrounding context that explains how the request was assembled and why a particular receipt was eligible, selected, or already tied to another active workflow state.

9.2 Review, approval, denial, contest, cancellation, and decision chronology

We process reimbursement-review records including reviewer identity or role context where applicable, decision timestamps, comments, explanations, approval history, denial history, contest records, cancellation records, and other state-transition history showing how a request moved through the workflow. In current product use, reimbursement handling may involve both admin-side review and member-side responses in later stages. As a result, reimbursement data may reflect not only a final outcome, but also a chronology of review, challenge, response, and resolution that can remain relevant for support, auditability, disputes, and fraud analysis.

9.3 Payout-method information and destination-sensitive metadata

We process payout-method information and destination-sensitive metadata, which may include payout-method type, masked or partially displayed destination details, payee or account-holder fields, default-method selections, method status, update history, validation-related context, and related identifiers. The current member-facing workflow may emphasize bank-account-style payout destinations, but the privacy issue is broader than one display format. Even where these records are not fully visible in product screens, they may still qualify as highly sensitive information because they are tied to where value is intended to be routed and because disputes may later turn on who changed, confirmed, selected, or relied on a destination record.

9.4 Payout-method change history, selection history, and operational validation context

Payout-method records may also include when a method was added, updated, replaced, removed, set as default, or otherwise modified, along with actor and timestamp context showing who performed the change and when. We may process records related to method validation, exception handling, support review, or wrong-destination investigations where those issues arise. In GeriPay, payout-method data therefore is not limited to a static destination snapshot. It can also include a change trail that becomes important if a payment is challenged, a method is suspected to be stale or unauthorized, or support later needs to reconstruct which destination record was active at a particular time.

9.5 Payment-history events, payout outcomes, and downstream-provider context

We process payment-history entries, payout-state labels, outcome timestamps, retry and failure history, return or reversal indicators, provider-reported or provider-affected event context, and other operational records associated with payout outcomes. These records may reflect an event trail rather than a single final settlement fact at every moment they are viewed. They may therefore be reused for support, reconciliation, fraud analysis, reporting, audit, or dispute handling even when the underlying downstream outcome remains complicated or evolving. Payment-history records may also affect or explain linked reimbursement status, linked receipt payment status, or later reporting outputs.

9.6 Internal visibility, reconciliation, support, and dispute handling for reimbursement and payout records

Reimbursement, payout-method, and payment-history records may be visible to different audiences for different reasons, including the submitting member, admins or reviewers acting under workspace authority, and GeriPay personnel handling support, security, fraud, incident, or legal-response issues where review is necessary. These records may also be revisited for reconciliation, duplicate-claim review, wrong-recipient disputes, timing disputes, fraud analysis, or challenges to whether a payout destination or payment-history entry accurately reflected the state of the workflow at a given moment. In other words, reimbursement and payout records are both operational workflow data and part of the product's later evidence picture.

9.7 Cross-record linkage, persistence, and preserved workflow history

Reimbursement and payout records may be linked to receipt records, SmartScan outputs, report-generation history, users, organizations, provider messages, support tickets, fraud-review files, legal requests, and preserved evidence. That linkage is important because it explains why reimbursement- and payment-history data may remain visible internally, remain preserved after ordinary workflow completion, or be re-examined later in support, fraud, incident, legal, or rights-handling contexts. Closing a request, removing a payout method from current use, or changing a visible status does not necessarily erase the underlying historical record of how the reimbursement or payout workflow unfolded.

Section 10. Reports, Exports, Verification Codes, and Public or Semi-Public Verification Data

10.1 Report-generation requests, selected inputs, and scope records

We process report requests, selected input records, generation timestamps, actor context, scope or filter context, and related information showing what was included in or associated with a report or export. In GeriPay, report-generation data may reflect not only that a file was created, but also what receipts, reimbursement records, payment-history entries, date ranges, user or organization scope, and workflow context were used to assemble the final output. That means the report-generation layer is itself a meaningful record family and not merely a technical prelude to a downloadable PDF.

10.2 Generated report artifacts, verified PDFs, and stored-output metadata

We process generated files, export artifacts, preview records, retrieval-linked metadata, stored report identifiers, file linkage, regeneration history, and other information associated with a report or verified PDF. Reports, PDFs, and similar artifacts are their own data family within the Service because they combine underlying workflow records into a new output with its own storage, delivery, visibility, and retention consequences. The fact that a report is generated from prior records does not make it redundant. The generated artifact may persist, be previewed, be re-downloaded, be replaced, or remain relevant for later verification, support, fraud review, or disputes.

10.3 Verification codes, access-enabling references, and artifact linkage

We process verification codes and similar access-enabling references used to connect a viewer to a report, verified PDF, or verification surface outside ordinary workspace authentication. These codes and references may be linked to specific generated artifacts, may remain associated with later access events, and may make certain information visible to code holders or public viewers who are not otherwise logged into the originating workspace. Verification codes may be stored in one internal form and displayed in a human-readable formatted form for verification use, but in either case they are treated as a distinct privacy-relevant category because possession of the code can affect visibility.

10.4 Public or semi-public verification surfaces and outward-facing artifact context

Some GeriPay-generated artifacts may be viewable through the public verification page, other public or semi-public verification surfaces, linked previews, or similar outward-facing surfaces. We process information displayed through those verification contexts, including data showing that a report exists, that a code is valid or invalid, that a generated artifact is linked to the code, and that a preview or report-linked output remained available at the time of access. This outward-facing context is intentionally treated differently from internal workspace use because it involves different audiences, different monitoring concerns, and different sharing consequences. A record that was created in a private workspace may therefore later have a limited outward-facing validation or viewing layer.

10.5 Public verification-page access events, request telemetry, and abuse-monitoring logs

We process access-event logs, request telemetry, IP-related context, browser and device context, rate-limiting and abuse-review signals, and other records created when the public verification page or other public or semi-public verification surfaces are used. This can include records showing when a code was submitted, when a viewer attempted to load a preview, when access failed, whether repeated requests suggested scraping or misuse, and what technical context surrounded the verification event. These verification-surface logs are part of the privacy picture because they concern not only internal users, but also external viewers, code holders, and unauthenticated requestors interacting with GeriPay's public-facing trust layer.

10.6 External sharing consequences and downstream visibility beyond GeriPay

Organizations, users, or code holders may share reports, PDFs, verification codes, links, or screenshots outside the Service. Once that happens, GeriPay may not control every downstream copy, forwarding action, screenshot, external storage location, or later viewer. At the same time, GeriPay may continue to retain internal records about how the artifact was generated, linked, shared, accessed, or preserved even if visibility of the user-facing artifact later changes. This is one reason the privacy treatment of reports and verification cannot stop at the moment a PDF is downloaded or a code is created.

10.7 Preserved report history, verification history, and dispute-use records

Report and verification data may later be revisited in support, fraud analysis, audit, incident response, legal response, or disputes over authenticity, scope, timing, or access. We also process records showing who generated a report, what source records were used, what code was linked to it, whether a public verification event occurred, whether a preview remained available, and what internal or outward-facing access history existed. As a result, reports and public or semi-public verification-surface data in GeriPay should be understood as a layered record family that includes private generation context, stored artifacts, code-linked access, public-surface telemetry, and preserved evidence about how those pieces fit together over time.

Section 11. Legal-Acceptance Evidence and Audit Records

11.1 Typed-name signatures, accepted-party context, and assent-linked identity records

We process typed-name signatures, accepted-party context, account linkage, membership linkage, workspace linkage, role context, and related legal-acceptance records generated when users accept the Terms, the Privacy Policy, electronic-records consent language, or related legal materials. In GeriPay, these records are not a cosmetic formality or a generic checkbox event. They connect a person, an account, a workspace relationship, an access state, and a specific legal ceremony. Because a legal-acceptance event may occur during signup, invite completion, re-consent, or another access-related event, the acceptance record can also help explain under what circumstances the user became entitled to continue using the Service.

11.2 Accepted document references, version linkage, and integrity-supporting context

We process accepted document references, version labels or identifiers, archived or historical document linkage, and integrity-supporting context showing what legal record was presented and accepted at the time of the ceremony. Depending on the system context, this may include references tying the acceptance to a particular version of the Terms or Privacy Policy rather than to a generic current document. GeriPay may also maintain supporting evidence such as archived copies, integrity markers, or linked acceptance metadata so the system can later reconstruct what legal text was associated with the event if the live policy or legal page changes later.

11.3 Ceremony chronology, completion milestones, and technical metadata

Where available and depending on the acceptance flow and system state, we process timestamps, sequence records, scroll-completion or review-completion milestones, route context, session context, IP-related information, browser and device details, locale and timezone context, and other technical or event evidence associated with a legal-acceptance ceremony. These records help document how the ceremony occurred, in what order relevant steps happened, and in what technical environment assent was captured. They are part of an evidence system designed to show that a real acceptance event occurred in a real account and session context. The available evidence can vary by workflow, device behavior, page state, and operational conditions. At the same time, the existence of completion or chronology metadata should not be read as a guarantee that GeriPay can prove every disputed fact with perfect certainty in every future case.

11.4 Audit trails, duplicate evidence layers, and ordinary-course system records

We process audit logs, duplicate evidence records, acceptance-event trails, route and session linkage, and other ordinary-course system records that support later review of legal-acceptance evidence. These audit layers may show when the ceremony began, when it was completed, what account or workspace it was tied to, what technical context surrounded it, and how later support, security, or legal teams can locate the record. In a product that relies on organization-managed invites and workspace access, these audit records can become especially important when questions later arise about stale authority, impersonation, or whether a person actually completed the applicable legal step.

11.5 Later operational, legal, and preservation uses of acceptance evidence

Legal-acceptance evidence may later be used to troubleshoot onboarding problems, investigate suspicious acceptance patterns, respond to privacy or contract disputes, support legal compliance, preserve evidence, and defend the Service in later claims or audits. For that reason, legal-acceptance evidence in GeriPay should be understood as one of the strongest examples of information that may remain important long after ordinary account activity, current membership, or current user-facing access changes. The future retention section elaborates on those preservation realities, but the category itself should already be understood here as a durable evidence family.

Section 12. Device, Browser, Session, Cookie, and Usage Information

12.1 Request, browser, device, and network telemetry

We process request-level logs and technical telemetry such as request timestamps, pages, routes, APIs, outcomes, failures, retries, IP addresses, network context, user-agent strings, browser family or version context, device type, operating-system context, locale, language, and timezone information. These records help run, secure, troubleshoot, localize, and understand the Service, and they may be created in both authenticated and unauthenticated contexts, including public verification use. In GeriPay, this technical layer is important not only for ordinary website operations, but also for reconstructing how a user moved through sensitive workflows such as login, invite acceptance, receipt upload, SmartScan review, reimbursement creation, report generation, or public verification access.

12.2 Session identifiers, client continuity records, and session-lifecycle history

We process session identifiers, client identifiers or comparable continuity records, sign-in events, signup-linked or invite-acceptance-linked session creation, refresh events, remembered-state context, logout history, expiration history, invalidation history, revocation history, and related account-linked session records. These records support authenticated continuity and session integrity, but they also matter for account security, investigation of suspicious access, support verification, and later evidentiary review of who likely had access and when. Because workspace access in GeriPay can expose receipts, reimbursement records, payout-method information, reports, and legal-acceptance history, session and client continuity records are among the most operationally sensitive technical records in the Service.

12.3 Cookies and similar browser-state technologies

We process information through cookies and similar browser-side technologies used for essential product functions, session continuity, security, login integrity, workflow continuity, preference storage, and related operational needs. Some browser-side technologies are used because the Service cannot maintain secure authenticated continuity without them. Others may help preserve a smoother experience across multi-step flows or maintain preferences or presentation state. If these technologies are blocked, cleared, or disabled, parts of the Service may not work as intended, authentication may be interrupted, invite or login flows may break, and some continuity, security, or usability features may be limited. For that reason, cookies in GeriPay should not be understood only as a minor website convenience tool.

12.4 Usage telemetry, workflow-interaction telemetry, and public-surface telemetry

We process workflow interaction telemetry, page and feature usage patterns, verification lookups, preview attempts, navigation events, interruption points, repeated retries, and other activity records showing how people move through the Service. This telemetry can come from private authenticated workflows, such as receipt review or reimbursement handling, and from outward-facing or unauthenticated surfaces, such as public verification-page access. The same technical data may therefore support product continuity, support diagnosis, abuse monitoring, and later disputes about what was accessed, when, and under what circumstances.

12.5 Operational logs, diagnostics, and incident-reconstruction records

Technical records may also include access logs, authentication logs, session logs, error logs, diagnostics, and other machine-generated records used to investigate service problems, detect anomalies, understand compatibility issues, and reconstruct incidents. These records may exist even when users never see them directly. They can be especially important when GeriPay needs to analyze broken upload flows, repeated login failures, unusual verification traffic, session-revocation events, public-surface misuse, or other security and reliability issues. As a result, technical records in this section should not be read as a generic analytics bucket alone.

12.6 Abuse indicators, anomaly signals, and security-supporting technical context

Telemetry may also be evaluated to produce or support anomaly indicators, hostile-automation indicators, suspicious request patterns, scraping signals, account-takeover indicators, session-risk indicators, and other security-supporting technical context used for diagnostics, analytics, platform protection, abuse monitoring, fraud prevention, and incident response. These derived signals may later affect review, escalation, containment, or preservation decisions. They should not be understood as generic analytics alone; they are also part of the Service's security and evidentiary infrastructure.

Section 13. Communications, Support, and Service Interaction Records

13.1 Transactional communications and service notices

We process invites, verification messages, password-reset messages, settings-security messages, account notices, policy notices, service updates, and other transactional or operational communications sent in connection with the Service. That may include the message itself, recipient and sender context, timestamps, delivery metadata, and interaction records showing how the communication moved through the Service or through provider-supported delivery systems.

13.2 Support, troubleshooting, and operational interaction records

We process support tickets, troubleshooting messages, screenshots, attachments, support-case identifiers, routing records, diagnostic references, and operational correspondence linked to user, workspace, receipt, reimbursement, report, verification, or access issues. In resolving a support issue, GeriPay personnel may need to review underlying records associated with that issue, which means support records can become linked to account records, workflow records, technical telemetry, and preserved evidence.

13.3 Complaints, disputes, legal requests, and preservation-trigger interactions

We process complaints, abuse reports, fraud reports, legal requests, privacy requests, dispute communications, regulatory contacts, and other interactions that can trigger deeper review, escalation, or preservation. These records often become more important over time, not less, because they may define when a dispute began, what problem was alleged, what evidence needed to be preserved, and how GeriPay responded or coordinated with organizations, providers, advisors, or authorities.

13.4 Communication metadata, service-side notes, and provider-supported delivery context

We may also process delivery status, bounce handling, open or interaction context where available, provider-supported routing information, internal notes, escalation markers, and other operational communication metadata that helps explain how messages were sent, delivered, handled, retried, or reviewed. Those records may connect communications to provider-management, retention, incident handling, fraud review, and later legal or audit contexts, even if the original message began as an ordinary service notice or support exchange.

Section 14. How We Use Information

14.1 Purpose framework and multi-use interpretation rule

GeriPay may use the same information for more than one purpose, and the applicable purpose can depend on whether the context is organization-directed workspace use, GeriPay-controlled platform operation, or a mix of both. A receipt image, reimbursement record, session log, verification event, or support ticket may begin in one context and later be used in another without changing its basic identity as a product record. For that reason, this section should be read as a purpose map rather than as a promise that each data category has one exclusive use. In a multi-user, provider-dependent workflow product, information is often used across operation, support, fraud review, legal response, and continuity functions at the same time.

14.2 Account, onboarding, authentication, and workspace-operation purposes

We use information to create accounts, verify email addresses and other account states, link users to organizations and workspaces, manage invites and onboarding, authenticate access, maintain sessions, apply role-based permissions, enforce deactivation or removal decisions, and support the ordinary operation of member and admin workspaces. These uses are fundamental to letting the Service know who a user is, what workspace they belong to, what they are allowed to do, and what records they may access or act on. Without these uses, GeriPay could not reliably operate invite acceptance, login continuity, workspace governance, admin controls, or member-facing workflow surfaces.

14.3 Receipt, SmartScan, reimbursement, payout, payment-history, report, and verification purposes

We use information to receive receipt uploads, create draft receipts, run SmartScan and related extraction processes, show review screens, store corrected or accepted receipt data, create or review reimbursement requests, manage payout-method records, display payment-history events, generate reports and verified PDFs, issue and manage verification codes, and operate public or semi-public verification features. These are not abstract "service provision" uses. They are concrete operational uses tied to the actual product flows that users and organizations rely on inside GeriPay. The same workflow records may also be reused to maintain consistency across linked product surfaces, such as keeping a saved receipt linked to a reimbursement request or linking a report to its verification artifact.

14.4 Communications, support, diagnostics, continuity, and product-improvement purposes

We use information to send invites, verification messages, password-reset communications, service notices, policy notices, support responses, and other operational messages; to respond to support requests and disputes; to troubleshoot broken flows, extraction issues, payout-method problems, report-delivery failures, or verification-surface issues; and to analyze how the Service performs over time. We may also use information to improve usability, extraction quality, workflow continuity, support handling, and overall reliability. Where appropriate and lawful, this work may involve transformed, disassociated, de-identified, aggregated, or otherwise lower-identifiability operational information derived from Service activity, logs, workflow metadata, historical records, or similar technical and operational artifacts, including for internal analytics, reliability review, security analysis, capacity planning, and service improvement. That said, product improvement is not the only or even the main reason many sensitive records exist. In many cases the record first exists because GeriPay needs it to operate, secure, or defend the Service, and only later may it also inform diagnostics or improvement work.

14.5 Security, fraud, abuse, and platform-protection purposes

We use information to detect suspicious logins, credential abuse, session misuse, hostile automation, scraping, manipulated uploads, reimbursement abuse, payout-destination anomalies, verification misuse, public-surface abuse, policy violations, insider misuse, and other security, fraud, or abuse signals. We may also use information to investigate suspicious activity, take protective action, preserve evidence, reduce the risk of future abuse, and maintain trust in sensitive features such as reimbursements, reports, public verification pages, and legal-acceptance systems. These uses are part of the basic protection model of the Service and are not limited to a narrow fraud-screening or analytics function.

14.6 Provider management, continuity, legal, audit, and evidence-preservation purposes

We use information to manage infrastructure and service providers, maintain continuity and recoverability, coordinate with providers during outages or incidents, preserve evidence, respond to legal process, support dispute defense, handle audits, enforce our rights, protect the Service, and comply with law or legitimate governance obligations. These uses help explain why records may persist or be revisited after ordinary workflow use ends. They also help explain why some information may move into logs, archives, provider-supported systems, legal files, or preserved evidence sets rather than remaining only in the user-facing workflow where it first appeared.

Section 15. How We Disclose Information

15.1 Organization, admin, and authorized workspace-user visibility as a disclosure category

Information may be visible to the organization managing the workspace, to admins, and to other authorized users according to role and workflow context. This internal visibility is a real disclosure consequence of using an organization-managed product, but it is not identical to outside-party disclosure. Different records may be visible to different people depending on their role, the feature being used, and the stage of the workflow. For example, visibility over receipt data, reimbursement data, payout-related data, report artifacts, or member-management history may differ. The important point is that the original submitter is not always the only person who can see or act on a record inside the workspace.

15.2 Service-provider, subprocessor, contractor, and agent disclosure paths

GeriPay may disclose information to providers, subprocessors, contractors, agents, and other parties acting on our behalf that host, store, analyze, secure, deliver, monitor, or otherwise support the Service. This can include disclosure for cloud hosting, database and storage support, communications delivery, logging and observability, security tooling, AI or OCR-supported processing, support tooling, public-surface delivery, and related technical functions. These disclosures are often part of ordinary product operation rather than rare exceptional events. The fuller provider section below explains these provider categories in more detail, but this disclosure section makes clear that information may move through outside support layers as part of how GeriPay actually runs.

15.3 Support, troubleshooting, security, fraud, and abuse-review disclosures

We may disclose information to internal teams, providers, specialists, organizations, or other appropriate participants as needed to investigate support issues, extraction problems, payout or report issues, suspicious activity, misuse, fraud, security incidents, or abuse of public or semi-public verification surfaces. These disclosures may involve receipt records, workflow history, support messages, technical logs, legal-acceptance evidence, or other linked records needed to understand the problem. Some disclosures may occur quietly in the background as part of a protected investigation, and not every affected person or organization will receive identical visibility into those investigative steps while they are underway.

15.4 Legal-process, protective, evidentiary, and rights-defense disclosures

We may disclose information to regulators, law enforcement, courts, outside counsel, insurers, auditors, and similar recipients when legally required or reasonably necessary to protect rights, safety, records, or the Service. This can include disclosures made in response to subpoenas, court orders, regulatory demands, preservation requests, fraud investigations, threatened claims, security incidents, disputes, or other situations where evidence or platform integrity must be protected. These disclosures may involve workflow records, technical records, legal-acceptance evidence, public or semi-public verification-surface records, support history, or preserved archives. In some cases notice may be delayed, narrowed, or not permitted while legal or investigative requirements are addressed.

15.5 Advisors, auditors, insurers, transaction counterparties, and diligence recipients

We may disclose information in audits, financing or transaction diligence, insurance-related matters, compliance review, restructuring, litigation preparation, and comparable business or legal contexts. Such recipients may include lawyers, accountants, auditors, consultants, insurers, financing sources, or potential transaction counterparties. Their access may be limited, contextual, and event-driven rather than part of routine day-to-day operations, but it can still involve sensitive business, technical, reimbursement, report, or acceptance-related records where those records are relevant to the matter under review.

15.6 Public verification, externally shared artifacts, and code-enabled visibility outside the workspace

Some information may be visible through public or semi-public verification paths or through artifacts shared outside the workspace by organizations or users. A valid verification code, shared report artifact, or outward-facing verification link can make limited information visible to people who are not otherwise authenticated members of the originating workspace. This is one of the clearest places where disclosure consequences arise from the design of the product itself rather than from a separate provider or law-enforcement request. Once reports, screenshots, PDFs, links, or codes are shared outside the Service, GeriPay may not control all downstream copying, storage, or redistribution.

15.7 Disclosure boundaries, layered visibility, and limited circulation

Not every recipient sees every category of information, and visibility can be layered, limited, role-based, event-driven, or artifact-specific. Internal workspace viewers, viewers of public or semi-public verification surfaces, service providers, advisors, insurers, auditors, authorities, and incident-response participants do not all receive the same data in the same way. Some records stay entirely internal to GeriPay systems unless a special need arises. Some are visible inside the organization-managed workspace but not to the public. Some become visible to code holders or report recipients but only in a narrower outward-facing form. This section should therefore be read as a map of disclosure paths, not as a statement that every record is broadly shared.

Section 16. Service Providers, Infrastructure Partners, and Subprocessors

16.1 Provider and infrastructure-partner category map

GeriPay relies on multiple categories of providers and infrastructure partners, including hosting and runtime providers, database and storage providers, file-delivery providers, communications providers, logging and observability providers, security-support providers, AI or OCR-supporting providers, support-tool providers, and other technical or operational partners. This section stays category-first rather than locking the policy into an unstable named-provider list, because provider relationships can change over time. The main privacy point is that GeriPay is not a purely self-contained system running on one isolated stack. Sensitive records may pass through several outside service layers in order for the product to function.

16.2 Provider-supported processing paths across real product flows

Provider layers support receipt uploads, image processing, SmartScan and related extraction workflows, account and session handling, public and authenticated page delivery, report generation, verification delivery, communications, logging, monitoring, storage, backups, and support or incident handling. In other words, providers are not only background infrastructure. They are part of the real path by which account data, uploaded materials, extracted outputs, reimbursement records, report artifacts, verification events, and technical telemetry move through the Service. This is why the provider discussion belongs in the Privacy Policy itself and not only in a backstop risk clause elsewhere.

16.3 Subprocessors, layered provider stacks, and indirect infrastructure chains

Providers may use affiliates, subprocessors, subcontractors, and indirect infrastructure layers of their own. As a result, some GeriPay processing may pass through layered provider stacks rather than through a single direct vendor relationship that GeriPay fully controls end to end. This layered structure can affect visibility into where records travel, how long certain logs or backups persist, what subservices are involved in an incident, and how quickly facts can be confirmed when something goes wrong. GeriPay can manage its provider relationships, but it may not have direct operational control over every indirect layer used by an upstream provider.

16.4 Infrastructure geography, regions, cross-border processing, and provider-location change

Providers may operate in multiple regions and jurisdictions, and processing geography may change over time because of infrastructure changes, routing changes, support paths, failover choices, provider substitutions, or updated provider configurations. This can affect where information is stored, transmitted, replicated, backed up, reviewed, or restored. The Service may therefore involve processing in the United States and in other jurisdictions, and region-specific assumptions may change over time. The later international-processing section addresses the rights and legal-basis side of this issue; this provider section addresses the operational reality that geography is often shaped by layered infrastructure decisions rather than by one simple fixed storage location.

16.5 Provider-side storage, backups, archives, deletion lag, and restoration limits

Provider systems can create backups, archives, replicas, logs, and delayed-deletion states that outlast front-end visibility or ordinary workflow use. A stored file, a database record, a preview artifact, a log entry, and a backup copy may not all have the same deletion path or restoration behavior. Some provider-layer records may remain for a time after an item is removed from the user-facing product. Some restored states may bring back certain database records or operational contexts without perfectly recreating every deleted file or derived artifact. These realities help explain why deletion and restoration should not be read as perfectly synchronized across all systems.

16.6 Provider-side misuse, misconfiguration, outages, incidents, and control limitations

Providers may experience outages, mistakes, misuse, compromise, policy changes, feature changes, misconfiguration, service degradation, or other problems that affect GeriPay's handling of information. The Privacy Policy should not overstate GeriPay's control over those environments. Even where GeriPay selects and manages providers carefully, GeriPay does not fully control provider personnel, provider reporting speed, provider regional behavior, provider remediation choices, or every retention and restoration detail inside provider-managed systems. These control limits matter for privacy because they can affect availability, confidentiality, incident timing, disclosure timing, deletion timing, and later reconstruction of what happened.

16.7 AI-provider, cloud-provider, storage-provider, and communications-provider specific risk disclosure

Different provider categories create different processing realities. AI or OCR-supporting providers may process uploaded content or derived outputs to help interpret receipt materials. Cloud and runtime providers may affect how authenticated and public surfaces are delivered and maintained. Storage and database providers may affect how files, previews, structured records, logs, and backups are retained or restored. Communications providers may handle invites, verification messages, password-reset notices, security codes, and support-related delivery. Logging and observability providers may receive technical telemetry and incident-support records. Category-specific disclosure matters because each provider family can shape confidentiality, integrity, timing, availability, or restoration in a different way.

16.8 Public-surface delivery, public verification, and edge or CDN-supported processing

Public pages, legal pages, and verification surfaces may rely on additional delivery layers, such as edge routing, CDN-like systems, network-delivery infrastructure, and other public-surface support paths that are not identical to private workspace processing. Those outward-facing surfaces may therefore generate distinct provider-handled access logs, request-routing records, caching behavior, or abuse-monitoring data. This is particularly important for report verification and public trust surfaces, where the product's outward-facing visibility model can cause information and telemetry to move through provider paths that do not arise in the same way during ordinary private workspace use.

16.9 Provider coordination for support, security, investigations, incidents, and legal response

Provider coordination may occur during troubleshooting, fraud review, incident response, legal process, audits, and similar events. In some situations provider involvement increases because GeriPay needs help locating logs, diagnosing failures, assessing outage or incident scope, preserving evidence where possible, supporting restoration efforts, or responding to legal and regulatory demands. That means provider access or provider visibility can expand in stressful or exceptional situations even if day-to-day operation appears more limited. It also means GeriPay's knowledge and communications about an event may depend in part on what providers can confirm, what providers are willing or able to disclose, and when those facts become available.

16.10 Rights-routing, deletion limitations, and organization-versus-GeriPay control in provider-supported processing

Provider-supported records can complicate deletion timing, request routing, and practical control. Some records may be organization-directed even though providers process them on GeriPay's technical stack. Some records may be GeriPay-controlled because they exist primarily for session integrity, support, logging, fraud review, legal defense, or provider management. Provider-backed logs, archives, and backups may also limit how quickly or completely certain data can be deleted or exported. For that reason, the provider discussion connects directly to later retention and rights sections and helps explain why responses to privacy requests may depend on both role allocation and infrastructure realities.

Section 17. Analytics, Diagnostics, Security Monitoring, and Fraud Review

17.1 Security, anomaly, and abuse indicators derived from telemetry

In this section, analytics means operational diagnostics, product performance review, security monitoring, and fraud review. It does not mean third-party advertising profiling or selling behavioral dossiers. GeriPay may interpret telemetry, workflow history, public-surface access events, and other technical or operational signals to identify possible abuse, suspicious behavior, or operational anomalies. This can include mismatches between ordinary and unusual request patterns, repeated failures, unusual route usage, verification-surface anomalies, extraction irregularities, or other patterns that suggest something may require closer review. These signals do not always prove misconduct on their own. They may instead indicate that GeriPay needs to investigate further, preserve records, or apply temporary protective measures while the facts are still developing.

17.2 Account-takeover, session-theft, and credential-abuse monitoring signals

GeriPay may monitor for suspicious sign-ins, unusual device or browser shifts, repeated failures, spoofing, compromised recovery flows, session misuse, session-theft indicators, or other integrity signals tied to authentication and continuity. Because an authenticated account can expose sensitive records and actions across receipts, reimbursements, payout methods, reports, and workspace administration, these signals may trigger heightened review or protective action even when the underlying cause has not yet been conclusively established. The purpose of this monitoring is to reduce risk and protect the Service, not to guarantee perfect detection of every compromised-account scenario.

17.3 Public verification, scraping, and hostile-automation protection signals

Public verification and other outward-facing surfaces may be monitored for scraping, code-guessing, automated attacks, unusual traffic, repeated verification lookups, suspicious preview attempts, or other patterns that could undermine the integrity or availability of the trust-oriented parts of the product. This monitoring is especially important because public or semi-public verification features can be accessed by outsiders who are not logged into a workspace. Outward-facing telemetry therefore serves not only diagnostics or performance purposes, but also active protective purposes designed to preserve the usefulness and credibility of public verification.

17.4 Fraud, policy-violation, and internal-misuse review signals linked to product workflows

Fraud review in GeriPay is product-specific rather than limited to generic account monitoring. Signals may arise from suspicious receipt uploads, manipulated source materials, inconsistent SmartScan outputs, unusual reimbursement behavior, payout-method anomalies, payment-history irregularities, report or verification misuse, stale-authority actions, delegated-access misuse, insider misuse, or other policy-violation patterns. Technical data may be reviewed together with workflow history, workspace authority context, support records, and provider-reported events so GeriPay can understand whether a concerning pattern reflects normal error, abnormal risk, or deliberate abuse.

17.5 Monitoring, alerting, provider coordination, and escalation records

Monitoring may generate alerts, escalation logs, internal review notes, provider coordination records, and other operational evidence that supports response, containment, and later analysis. Some alerts may remain internal operational records. Others may lead to support review, incident handling, fraud investigation, law-enforcement coordination, or evidence preservation. Providers may also become involved when monitoring depends on outside observability systems, hosting layers, storage systems, AI-processing paths, public-surface delivery infrastructure, or communications-delivery systems. These escalation records are part of the Service's operational evidence picture and can remain important even after the immediate issue appears resolved.

17.6 Retention, evidentiary preservation, and request limitations for fraud-prevention signals

Fraud, abuse, security, and anomaly records may be retained longer than ordinary user expectations would suggest because they may be needed to investigate suspicious behavior, support incident response, respond to disputes, protect the Service, or comply with law. This can include retention of the underlying logs, alerts, review notes, linked workflow records, provider messages, support history, or other supporting evidence tied to the signal. As a result, deletion, access, or similar privacy requests may be affected by the need to preserve relevant records while a matter is assessed, defended, or monitored for recurrence.

Section 18. Data Retention, Archival Copies, Backups, and Deletion Limitations

18.1 Retention framework, category-specific logic, and overlapping retention reasons

Retention in GeriPay is category-specific, context-specific, and purpose-specific. Different rules may apply depending on whether the information concerns account access, workspace governance, receipt uploads, SmartScan outputs, reimbursement workflows, payout-related records, report and verification artifacts, legal-acceptance evidence, support records, or technical logs. The same record may also be kept for more than one reason at the same time. A receipt-related record, for example, may remain relevant not only for the original workflow, but also for support, fraud review, report traceability, dispute handling, or legal preservation. For that reason, this section should not be read as if the Service uses one universal retention clock for every record.

18.2 Active records, inactive historical records, archived records, preserved evidence, and deletion states

Some records remain active because they are still used in current workflows or still visible in the product. Others become inactive historical records that no longer drive day-to-day workflow decisions but are still kept to preserve continuity, explain what happened, or support later review. Still others may move into archived or reduced-access states, preserved-evidence states, or deletion-related states that limit ordinary visibility while not yet resulting in total erasure everywhere. This means that a record can stop appearing in an ordinary interface without being immediately and universally deleted across logs, archives, backups, provider layers, or preserved evidence stores.

18.3 Account, workspace, membership, and access-lifecycle retention after closure, deactivation, removal, suspension, or termination

Account and relationship records can remain after a person loses access, changes role, is deactivated, is removed from an organization, or otherwise stops actively using the Service. GeriPay may keep identity, invite, verification, session, role-history, membership-history, admin-action, and workspace-governance records because they remain important to auditability, support, fraud prevention, legal response, incident reconstruction, or later disputes over who had access and when. In a role-based workspace product, the fact that someone no longer appears as an active user does not eliminate the need to preserve the historical evidence of that person's relationship to the workspace.

18.4 Receipt-upload, SmartScan, extraction-output, review-correction, and source-traceability retention

Source materials, draft receipt records, saved receipt records, extracted fields, review edits, correction history, traceability data, evidence markers, and related SmartScan records may persist for workflow, support, audit, fraud, incident, reimbursement, reporting, or dispute reasons. Source images and derived structured outputs may not have identical lifecycles, and review history may persist even after the visible workflow appears complete. This is important because GeriPay's receipt-processing architecture is layered: original uploads, draft-stage output, corrected or accepted values, saved records, and evidence metadata can each have continuing relevance in different later contexts.

18.5 Reimbursement, payout-method, payment-history, report, Verified PDF, and public or semi-public verification-surface retention

Workflow and outward-facing artifact records may also have long-tail retention. This can include reimbursement requests and decision chronology, payout-method metadata and change history, payment-history event trails, report-generation history, generated PDFs, verification codes, verification-page records, and public-surface access logs. Outward-facing artifacts may follow a different lifecycle from the underlying private workflow records that contributed to them. A report preview may become unavailable while verification metadata remains, or a payout method may be replaced while historical records about the prior destination continue to matter for disputes or reconciliation. For that reason, related record families should not be assumed to disappear together.

18.6 Legal-acceptance evidence, audit trails, and enforceability-supporting record retention

Acceptance evidence, audit trails, integrity-supporting records, and related logs may be retained for long periods because they support enforceability, legal response, version reconstruction, and later disputes about what legal record was accepted and under what circumstances. In GeriPay, legal-acceptance evidence is not incidental metadata. It is a dedicated evidence family tied to account access, onboarding, invite completion, and later defense of the Service. Even if a user stops using the product, those records may still need to remain linked to account, workspace, session, and document-version context.

18.7 Telemetry, session records, request logs, support records, and other operational-log retention

Operational logs and support history may have different retention patterns from visible workflow records. GeriPay may retain request logs, authentication logs, session-lifecycle records, public verification-page and verification-surface telemetry, diagnostics, support tickets, complaint history, incident-support records, and other operational evidence because those records help keep the Service secure, troubleshoot problems, explain historical events, and defend the platform. Clearing browser state or deleting a visible workflow record does not necessarily erase the related server-side telemetry, session history, support notes, or preserved diagnostic traces associated with the same event.

18.8 Archived copies, reduced-access storage, and historical business records

Some records may move into archival or reduced-access states rather than being fully erased. Archived records may still be preserved for integrity, continuity, audit, reconciliation, fraud review, historical business reference, or legal reasons even if they are no longer part of active user-facing workflow. GeriPay may retain such records to explain what happened in a reimbursement review, payout-related workflow, report-generation event, verification event, or membership-change sequence long after the original day-to-day activity has ended. Archived does not necessarily mean easy to access, but it also does not mean eliminated.

18.9 Backups, disaster-recovery copies, point-in-time recovery, and restoration-support records

Backups and continuity layers may create additional retained copies that are not instantly editable or removable. These may include database backups, snapshots, recovery-support copies, and other continuity layers designed to help recover the Service after failures or serious incidents. Backup copies may exist on schedules different from active systems. Restoration may also happen in stages and may recreate some data layers differently from others. This means that backup and restore behavior should not be understood as perfectly symmetrical with front-end deletion or with the visible state of the product at any one moment.

18.10 Provider-layer replication, storage metadata, file-object asymmetry, and deletion lag

Provider systems may retain file metadata, message metadata, logs, replicas, and residual artifacts even when user-facing records have changed or been removed. A stored file object, a database row, a preview artifact, a verification-linked reference, a backup copy, and a log trail may all behave differently across deletion and restoration events. In particular, storage objects and structured metadata may not always be deleted, restored, or retained in identical ways. Provider-layer asymmetry and deletion lag are therefore part of the real retention model of GeriPay and not merely obscure technical edge cases.

18.11 Fraud, abuse, sanctions, compliance-review, and internal-investigation preservation

Suspicious or sensitive matters can trigger longer retention of relevant records, including fraud signals, support interactions, receipt images, SmartScan outputs, reimbursement history, payout-related records, report and verification logs, and technical evidence. This can happen when GeriPay needs to investigate suspected manipulation, impersonation, account takeover, suspicious reimbursement or payout behavior, compliance concerns, sanctions-evasion concerns, bribery- or corruption-related warning signs, or other policy-violation scenarios. Retention may expand because the Service must preserve a reliable record while the matter is assessed, not because GeriPay has already reached a final conclusion.

18.12 Security incidents, forensic preservation, provider notices, and post-incident evidence retention

Incident-related logs, provider reports, forensic notes, response records, preserved configurations, and other evidence may be kept after suspected or confirmed security events. This can include retention of affected workflow records, support records, technical logs, public-surface access records, provider notices, communications, and related materials needed to investigate, contain, remediate, or later explain the event. Incident-driven preservation can continue even after the most visible operational issue ends, and it can affect deletion timing, disclosure timing, and later rights handling.

18.13 Legal holds, threatened-claim holds, audit holds, and dispute-record preservation

GeriPay may preserve records in response to legal holds, anticipated disputes, threatened claims, audits, investigations, or similar obligations. This may involve preserving reports, verification artifacts, acceptance evidence, support records, reimbursement or payout history, workspace-governance records, technical logs, and other linked workflow history while the matter remains unresolved. Ordinary deletion processes can therefore be paused, narrowed, or delayed when a dispute, audit, regulatory inquiry, or preservation demand makes that necessary.

18.14 Delayed deletion, partial deletion, de-identification, aggregation, and residual records

Not every deletion request or deletion event can result in complete erasure across every system. Deletion may be delayed, staged, partial, or technically constrained. Some records may be removed from active user-facing systems while residual traces remain in logs, archives, backups, provider layers, or preserved evidence stores for a period of time. Some information may instead be disassociated, transformed, de-identified, aggregated, or otherwise retained in a lower-identifiability form where appropriate and lawful. This section is one of the clearest places where GeriPay must be candid that deletion is not always immediate, universal, or identical across all layers of the Service.

18.15 Organization-controlled data, GeriPay-controlled data, and request-routing limits for retention and deletion

Different actors may control different parts of the retention story. Some records remain because the organization controls the underlying workflow and needs the historical business record. Other records remain because GeriPay has independent security, support, provider-management, legal, or evidentiary reasons to preserve them. Provider realities can further complicate timing and practical outcomes. As a result, retention and deletion outcomes may depend on mixed-role analysis, infrastructure limits, and the category of record involved. Inability to delete a record immediately or completely does not necessarily mean a request was ignored; it may reflect the real operating constraints of a multi-layer, organization-managed product.

Section 19. Security Practices and Incident Response

19.1 Security-section framing, high-level safeguards, and anti-warranty posture

GeriPay may describe high-level safeguards and response practices in this Privacy Policy, but that description should not be read as a warranty of perfect security or perfect outcomes. The Service uses administrative, technical, and organizational measures designed to help protect information, accounts, workflows, files, communications, and public trust surfaces. Those measures may include access controls, session protections, provider management, storage protections, communications protections, monitoring, review processes, and incident-response practices. This section is meant to describe the real posture of the Service at a high level, not to provide an exhaustive security-control list or to guarantee that every protective measure will always work flawlessly.

19.2 Security measures as risk reduction rather than risk elimination

Security measures are intended to reduce risk, not eliminate it. Controls may fail, be bypassed, be misconfigured, be incomplete, be delayed, or prove insufficient against a particular threat. Threat actors, insiders, compromised users, compromised devices, compromised inboxes, provider failures, software defects, human error, and layered infrastructure problems can still create confidentiality, integrity, or availability incidents. A strong control in one part of the Service does not guarantee safety in every other part. This is especially true in a product like GeriPay, where account access, uploads, SmartScan, reimbursements, payout-related workflows, reports, public verification, and legal-acceptance evidence all interact across multiple technical layers.

19.3 No-perfect-security, no-perfect-detection, no-perfect-availability, and no-perfect-remediation language

No method of processing, storage, transmission, service delivery, or access control is completely secure. GeriPay does not promise perfect prevention, perfect awareness, perfect uptime, perfect restoration, perfect remediation, or perfect transparency after an incident. Even where GeriPay acts reasonably and seriously, incidents can still happen, detection can still be delayed, facts can still remain incomplete for a time, and service restoration can still be partial or imperfect. This policy therefore should not be read as a guarantee that sensitive records, verification surfaces, account sessions, public artifacts, or provider-supported systems will never experience compromise, corruption, misuse, or downtime.

19.4 Incident-source map across internal systems, provider layers, users, devices, and public surfaces

Incidents can begin in many places, including GeriPay-controlled application logic, storage or workflow systems, hosting or database providers, AI or OCR-supported processing paths, communications-delivery systems, observability systems, user accounts, user inboxes, browsers, devices, public verification pages, verification-code workflows, and other exposed layers. A single event may also span multiple layers at once. For example, a phishing or inbox-compromise issue can affect account access, while a provider outage can affect upload handling, SmartScan processing, report delivery, or public verification simultaneously. This layered-source model is part of the reason incident handling in GeriPay can be complex and fact development can be gradual.

19.5 Incident-category map and product-specific consequences

Incidents may include unauthorized access, account takeover, phishing, spoofing, social engineering, session theft, malware, ransomware, destructive attacks, provider outages, provider misconfiguration, data corruption, public-surface abuse, hostile automation, denial-of-service, insider misuse, software defects, and infrastructure failures. Depending on the event, consequences may include exposure of sensitive account or workflow records, loss of confidence in a saved receipt or report artifact, interruption of receipt-upload or SmartScan flows, delays or confusion in reimbursement or payout-related workflows, degraded or unavailable verification surfaces, corrupted or stale workflow state, or uncertainty around what legal-acceptance or audit evidence remains available and reliable at a given moment. The relevant harm is not limited to simple unauthorized disclosure. It can also include integrity and availability failures that affect how the product works and how much trust users can place in it during or after an event.

19.6 Awareness, detection, and provider-dependent visibility limitations

GeriPay may not know about incidents immediately. Some facts may come first from internal monitoring, some from users, some from organizations, some from support cases, and some from providers or later forensic review. Provider reporting may be delayed, incomplete, or revised. Certain signs may appear suspicious without proving that a true compromise occurred. Other serious issues may initially look like routine failures or user error. Different system layers may reveal different facts at different times. For that reason, early incident knowledge can be incomplete, and GeriPay's understanding of scope, cause, and affected records may develop gradually.

19.7 Early triage, containment, and protective actions

When GeriPay becomes aware of a possible incident, it may take protective action such as triage and severity assessment, forced sign-out, session invalidation, access restriction, reauthentication, password-reset handling, feature limitation, workflow interruption, temporary suspension of outward-facing verification features, evidence preservation, or coordination with providers, specialists, or advisors. These measures may be applied quickly and under imperfect information. Their purpose is to reduce harm, preserve integrity, and help the Service regain control of the situation, not to guarantee that all downstream consequences have already been prevented.

19.8 Provider incidents, provider reporting, subprocessor chains, and shared-responsibility limits

Some incidents may depend heavily on provider disclosures, provider timelines, provider remediation steps, and facts that move through subprocessor or indirect infrastructure chains before reaching GeriPay. A hosting, storage, database, AI, communications, logging, or edge-delivery provider can affect confidentiality, integrity, availability, timing, or restoration across many GeriPay workflows at once. GeriPay does not fully control provider personnel, provider security posture, provider incident reporting speed, or every technical and legal constraint on provider communications. This shared-responsibility reality is part of the actual security posture of the Service and not a hidden exception to it.

19.9 Investigation, forensics, evidence preservation, and internal review confidentiality

GeriPay may investigate incidents, preserve logs and workflow records, work with forensic or technical specialists, coordinate with providers, and limit what it discloses during active review where broader disclosure could interfere with the investigation, harm platform security, or violate legal constraints. Incident handling may involve review of account records, session history, receipt and reimbursement records, report and verification records, support history, acceptance evidence, and preserved technical materials. Some internal investigative detail, provider-supplied information, or security procedure information may remain confidential even when GeriPay communicates the general nature of an issue.

19.10 Notice timing, appropriateness, legal requirements, and audience-specific communications

Notice timing may depend on discovery, triage, provider input, legal requirements, regulatory obligations, law-enforcement constraints, the category of incident, and the audience involved. Different incidents may result in different notice paths, different levels of detail, and different timing. Some notices may go first to the organization that manages the workspace. Others may go to affected users, regulators, authorities, providers, or other parties where appropriate or legally required. This section should not be read as a promise that every event will produce immediate notice to every potentially affected person in identical form.

19.11 Partial facts, evolving facts, uncertain attribution, and revised conclusions

Early incident information may be partial, preliminary, or uncertain. Scope, attribution, severity, affected records, likely cause, and appropriate remediation can change over time as more facts emerge. Provider findings may arrive in stages. Internal and external conclusions may be refined, narrowed, expanded, or corrected later. Follow-up communications may therefore differ from earlier descriptions. That possibility should not be read as evidence of bad faith by itself; it is often a normal feature of incident development in layered systems with provider dependencies and multiple evidentiary sources.

19.12 Law-enforcement, regulatory, insurer, advisor, and government coordination

Incident handling may involve regulators, law enforcement, outside counsel, insurers, forensic experts, consultants, providers, and other appropriate third parties. Such coordination can affect what information is preserved, what disclosures are made, when they are made, and how much detail GeriPay can provide publicly or directly to users while the matter remains active. In some cases legal, investigative, or protective reasons may require restraint or delay. In other cases multiple overlapping duties may require GeriPay to communicate with different audiences in different ways.

19.13 Restoration, recovery, stale states, incomplete remediation, and post-incident confidence limits

Recovery may be partial, staged, stale, or incomplete. Some workflow states, uploads, previews, reports, verification artifacts, communications, or linked references may return at different times or not in exactly the same form as before the incident. Some records may remain unavailable, some data may remain uncertain, and some remediations may require changed settings, provider changes, access resets, or new operational controls. Even after service restoration, not every question may be fully resolved. This section therefore keeps clear distance from any suggestion that GeriPay can always return every feature, record, or trust signal to an exact pre-incident condition.

19.14 Post-incident retention expansion, dispute preparation, and rights-processing impact

Incidents can expand retention, increase provider coordination, affect rights timing, and create additional preserved records. GeriPay may retain more logs, communications, workflow history, provider messages, and investigative notes after an event than it would under ordinary circumstances. Requests for deletion, correction, access, or portability may be delayed, narrowed, or otherwise affected while relevant information is preserved for security, compliance, dispute preparation, insurance, audit, provider-claim, or legal-response purposes. This is one of the key ways the incident section connects to the retention and rights sections.

19.15 Public verification, trust surfaces, and outsider-reliance limits after incidents

Verification pages, verified PDFs, public previews, code-based access paths, and other outward-facing trust surfaces may require restrictions, temporary shutdown, review, warning states, or restoration changes after incidents. Provider conditions, abuse conditions, stale states, or evidence uncertainty can affect how much confidence outside viewers should place in a given outward-facing artifact during or after an event. GeriPay may therefore treat these public or semi-public surfaces differently from private workspace features during incident response. This does not mean the broader verification architecture is abandoned, but it does mean that outsider-facing trust features can be especially sensitive to security, provider, and integrity disruptions.

Section 20. International Processing, Legal Bases, and Privacy Rights

20.1 International-processing framing, geographic variability, and anti-uniformity warning

Information may be processed in multiple jurisdictions, and rights, obligations, and disclosure expectations can vary by location, provider path, record type, and legal regime. GeriPay should therefore not be read as offering one perfectly uniform global privacy experience in every context. The Service may operate through infrastructure, support, storage, logging, backup, or incident-response layers that span more than one region or jurisdiction. Different legal frameworks may apply to different people, different records, and different stages of the same workflow.

20.2 Cross-border processing drivers across hosting, storage, support, providers, backups, and incidents

Information may cross borders for practical reasons including hosting, storage, database support, file delivery, support access, provider relationships, backups, failover, fraud review, incident handling, and legal response. Cross-border movement in GeriPay is therefore not only a matter of where the main application is hosted. It can also arise through public verification delivery, report-access paths, provider coordination, archive and backup systems, security review, and restoration activity after failures or incidents. The same record may be processed in more than one geography over its lifecycle.

20.3 Transfer-framework and international-safeguard flexibility

Where international transfer safeguards are legally relevant, GeriPay may rely on contractual, legal, operational, or provider-based mechanisms that are recognized or appropriate under the applicable framework. The exact safeguard structure may vary by provider, processing path, jurisdiction, and legal change over time. For that reason, this Privacy Policy preserves flexibility rather than locking GeriPay into one fixed transfer mechanism or one fixed provider architecture forever. If additional jurisdiction-specific detail later becomes necessary, it may be provided through supplements or updated disclosures.

20.4 Role allocation between organization-directed processing and GeriPay-controlled processing

Mixed-role processing remains central to rights and cross-border handling. Some rights outcomes depend not only on the data category involved, but also on who is using the information, for what purpose, and under whose authority. Organization-managed workspace use may shape certain decisions about membership, internal visibility, reimbursement review, or report sharing. At the same time, GeriPay may independently process and retain the same or related information for authentication, session integrity, provider management, support, security, legal-acceptance evidence, incident handling, legal response, or defense of the platform. A rights answer that is accurate for one layer of processing may therefore not fully resolve every other layer of the same record family.

20.5 Organization-controlled data examples and first-line request routing

Some account, workspace, receipt, reimbursement, report, visibility, or sharing issues may need to be addressed first through the organization that manages the workspace. This can include internal role or membership questions, decisions about what users may upload into the workspace, which receipts or reimbursement records are reviewed or corrected internally, organization-governed workflow visibility, whether reports, exports, verified PDFs, verification-enabled artifacts, or similar materials are shared or relied on inside or outside the organization, and certain record-management or retention decisions the organization makes in the ordinary course of its own use of the Service. That routing reality does not eliminate GeriPay's own responsibilities, but it does mean that some requests cannot be handled accurately by ignoring the organization's role in the underlying workflow.

20.6 Limits of organization control and GeriPay's independent retention or response rights

Even when the organization controls the ordinary workflow use of a record, GeriPay may still retain or process related information independently for security, integrity, provider-management, support, incident-response, legal, audit, or evidentiary purposes. GeriPay may also need to preserve logs, legal-acceptance evidence, provider communications, fraud-review records, or historical technical evidence even where the organization would prefer a narrower operational view. This is one of the main reasons rights outcomes in GeriPay can be mixed, layered, and record-family specific rather than simple all-or-nothing results.

20.7 Legal-basis framework and legal-basis variability where applicable

Where legal bases matter, GeriPay may rely on contract performance, legitimate interests, legal obligations, consent in limited contexts, or other legally recognized grounds depending on the situation and the applicable law. GeriPay does not claim that one single legal basis supports all processing everywhere. The relevant basis can vary by whether the processing concerns account operation, SmartScan and workflow execution, support and diagnostics, monitoring and fraud prevention, provider coordination, legal-acceptance evidence, legal response, or post-incident preservation.

20.8 Legal-basis mapping by processing context

Where useful and legally relevant, legal-basis analysis may differ across account creation and session management, SmartScan and receipt workflows, reimbursements and payout-related operations, report generation and verification, support and diagnostics, security monitoring and fraud review, provider management, evidence preservation, and legal response. This mapping matters because some processing is central to performing the Service or supporting the organization's requested workflow, while other processing is central to protecting the Service, complying with law, or preserving evidence of what occurred. The legal-basis discussion should therefore be read together with the broader purpose and role-framing sections rather than in isolation.

20.9 Rights overview and anti-overstatement framing

Depending on applicable law, individuals may have rights such as access, correction, deletion, portability, restriction, objection, consent withdrawal in limited contexts, complaint, appeal, or related rights. Those rights are meaningful, but they are not absolute. Their availability and scope can vary based on jurisdiction, role allocation, record type, legal basis, retained evidence, technical feasibility, provider-backed persistence, and the rights of others. The same request may therefore produce different results for different layers of the same record family.

20.10 Self-service changes, organization-managed changes, and formal request paths

Some changes may be made directly by the user in the product. Some may be managed by admins or by the organization that controls the workspace. Others may require a formal request to GeriPay. Account-management tools, workspace-governance decisions, support interactions, and statutory privacy rights are not always the same thing. The existence of self-service editing or organization-managed controls does not necessarily mean that every legal rights request can be resolved through those tools alone.

20.11 Identity verification, authority checks, and anti-fraud safeguards for rights requests

GeriPay may require identity verification, account-control confirmation, workspace-linkage confirmation, or proof of authority before honoring a request. These checks help protect users, organizations, and the Service against impersonation, unauthorized disclosure, delegated-access abuse, and fraud disguised as a privacy request. If identity or authority cannot be adequately confirmed, GeriPay may limit, delay, or decline the request to the extent permitted by law. This verification step is part of responsible rights handling, not a mere administrative obstacle.

20.12 Authorized agents, representatives, admins, and delegated requestors

Requests made by agents, representatives, admins, or others acting for someone else may require additional proof of authority and may be evaluated differently depending on the workspace role, relationship, and applicable law. In an organization-managed product, an admin may have legitimate authority over some workspace issues while lacking authority to override all of an individual's direct privacy rights in every context. Representative handling in GeriPay therefore depends on both legal rules and actual product role boundaries.

20.13 Access, correction, deletion, portability, restriction, objection, and consent-withdrawal rights by category

The practical meaning of each right can vary by record family. Rights relating to visible account data may be different from rights relating to workspace-governance history, uploaded materials, SmartScan-derived outputs, reimbursement or payout-related history, public verification-page and verification-surface logs, support records, legal-acceptance evidence, or preserved technical logs. Some categories may be easier to access or correct than others. Some may be subject to stronger deletion limits or portability limits. Some may not depend on consent at all. GeriPay therefore does not present a one-size-fits-all promise that every right applies equally to every record.

20.14 Deletion and erasure caveats across workspace records, logs, archives, backups, and preserved evidence

Deletion can be delayed, partial, technically constrained, or unavailable for some records. The organization may control some workspace records. GeriPay may independently retain some records for security, legal, integrity, provider-management, acceptance-evidence, reimbursement-traceability, reporting-traceability, incident-response, or dispute reasons. Archives, backups, logs, preserved evidence, and provider-backed copies can further limit what deletion means in practice. User-facing disappearance is not the same thing as universal erasure across every layer of the Service. This is one of the strongest rights-limit caveats in the Privacy Policy.

20.15 Portability, extraction, and export limitations

Portability and export outcomes can depend on technical feasibility, provider format, product design, role allocation, and the nature of the records involved. Some data may exist in forms that are readily exportable to the user or the organization. Other records may consist mainly of linked workflow history, logs, derived records, preserved evidence, provider-backed metadata, or operational artifacts that do not translate neatly into a simple portable output. GeriPay therefore keeps portability expectations realistic and does not treat every request as equivalent to a complete system dump.

20.16 Objection, restriction, and consent-withdrawal limits in security, contract, organization-directed, and legal contexts

Objection, restriction, or consent-withdrawal requests may not stop processing that remains necessary for core service operation, contract performance, security, fraud prevention, incident response, provider coordination, legal compliance, evidence preservation, dispute defense, or organization-directed workflow handling where another valid basis applies. This is especially important in a business workflow product with public verification features, reimbursement and payout-related records, and layered provider-backed logs. Withdrawal of consent where consent is relevant also does not necessarily retroactively invalidate prior processing or eliminate processing supported by other lawful grounds.

20.17 Complaints, appeals, jurisdiction-specific notices, and region-specific supplements

Where applicable law provides them, complaint channels, appeals, supervisory-authority rights, or other jurisdiction-specific processes may be available. GeriPay may also provide supplements, region-specific notices, or tailored explanations where necessary to address different legal frameworks. Those supplements may clarify or add to the main Privacy Policy rather than replacing it entirely. This allows GeriPay to keep the main document readable while still preserving room for more specific obligations where legally required.

20.18 Public-surface, support, legal-acceptance, and incident-generated request contexts

Not every privacy request concerns ordinary private workspace records. Some may relate to public verification traffic, support messages, legal-acceptance evidence, session and telemetry records, or incident-generated records that exist mainly for security, forensics, or legal preservation. Those requests may require different routing, different verification steps, different explanations, or different limitations than a straightforward request about profile data or visible workspace content. This section is intentionally broad enough to match the real surface area of the product rather than only the most obvious account-management scenarios.

Section 21. Children, Minors, Sensitive Limitations, and Special Caveats

21.1 Business-use audience framing and non-child-directed posture

GeriPay is designed for business and organization-managed use. The ordinary expected user of the Service is an admin, member, invitee, workspace participant, or similar person acting in an organizational, reimbursement, receipt-management, reporting, support, or related operational context. GeriPay is not designed or presented as a consumer product for children, not intended to attract children as the primary audience, and not built as a youth-focused, entertainment-focused, or family-social service. It is also not presented as a specialized platform for pediatric, youth-profile, or child-directed record collection. This section should therefore be read together with the business-use and role-allocation framework used throughout this Privacy Policy rather than as if GeriPay were a child-directed consumer application.

21.2 No intentional child-directed onboarding, targeting, or unlawful underage collection

GeriPay does not intentionally direct the Service to children in violation of applicable law and does not knowingly design onboarding, account-creation, invite, targeting, or engagement flows for unlawful underage use where such use is prohibited. Age thresholds and legal tests can vary by jurisdiction, so this Privacy Policy does not attempt to lock the terms children or minors to one universal age in every legal regime. Instead, GeriPay states the more durable principle that it does not intentionally seek personal information from children in violation of applicable law and does not knowingly encourage unlawful underage use of the Service. At the same time, this statement should not be read as a representation that GeriPay operates perfect age-screening or perfect age-verification controls across every account path, upload path, support path, or organization-managed workflow.

21.3 Minors and child-related information appearing in organization-managed records

Even though GeriPay is not directed to children, information relating to minors can still appear in the Service through organization-managed activity. For example, an organization or its users may upload receipts, supporting documents, reimbursement-related materials, report content, communications, or other workflow artifacts that incidentally reference a child, dependent, family member, student, beneficiary, patient, traveler, or other minor. In those circumstances, child-related information may enter the Service through the organization's use of GeriPay rather than through direct onboarding of a child. Organizations and users remain responsible for ensuring that they are authorized to submit and manage the information they upload, that they use the Service lawfully, and that they do not use GeriPay to collect, disclose, or manage child-related information unlawfully. The possibility that child-related information can arrive through organization-managed records is one of the main reasons this section must be read as part of GeriPay's mixed-role privacy architecture rather than as a simple direct-account disclaimer.

21.4 Actual-knowledge limits, incidental receipt, and no-perfect-age-screening language

GeriPay may not know the age, legal status, or relationship of every individual referenced in uploaded materials, SmartScan-derived records, support communications, reimbursement artifacts, report history, verification-related materials, or preserved logs. Information may be incomplete when first received, may be submitted indirectly by an organization or user, may only become apparent after later review, or may only become relevant during support escalation, fraud analysis, incident review, dispute handling, audit work, or legal preservation. For that reason, GeriPay does not promise perfect age awareness, perfect child-data detection, or perfect screening across every feature and record layer of the Service. The absence of immediate action should not be read to mean that GeriPay intentionally targeted children or had actual knowledge at an earlier point in time. This Privacy Policy preserves realistic room for incidental receipt, incomplete information, delayed awareness, evolving facts, and context-specific review.

21.5 Reporting paths, review, remediation, coordination, and lawful-response flexibility

If a parent, guardian, organization, user, representative, or other person with a good-faith basis believes that information relating to a child or minor has been submitted, used, disclosed, or made available through the Service in a manner that may violate applicable law or this Privacy Policy, that concern may be reported to GeriPay through the privacy contact channels described in this Privacy Policy. GeriPay may review the report, request information reasonably necessary to understand the context, coordinate with the relevant organization, restrict access, limit public or internal visibility, remove or disable content where appropriate, preserve relevant evidence, or take other steps GeriPay reasonably considers appropriate under the circumstances and applicable law. The exact response may depend on whether the issue involves organization-managed workspace content, support records, public verification artifacts, operational logs, archives, backups, provider-held materials, or other preserved record layers. GeriPay does not promise one rigid remediation path for every child- or minor-related scenario.

21.6 Children, minors, rights, retention, and mixed-role processing

Child- and minor-related issues in GeriPay are also shaped by the broader rules described elsewhere in this Privacy Policy. Requests involving deletion, access, correction, restriction, portability, objection, complaints, or similar issues may be affected by organization-managed control over certain workspace records, by GeriPay's independent security, support, incident-response, legal, and evidentiary needs, and by the fact that some records may continue to exist in logs, archives, backups, provider systems, or preserved investigation files even after active visibility changes or access is limited. GeriPay therefore does not present this section as a standalone promise of universal deletion, immediate removal, or identical handling in every jurisdiction and every context. Instead, child- and minor-related concerns are handled through the same mixed-role, retention-aware, provider-aware, and context-specific framework that governs the rest of the Service, while preserving additional care where child-related concerns are credibly raised.

Section 22. Policy Changes, Contact Information, and Effective-Date Mechanics

22.1 Policy-update framing, version-awareness, and purpose of the section

This section explains how GeriPay may maintain, update, version, communicate, and operationalize changes to this Privacy Policy. It is not intended to reduce privacy governance to a casual website-edit practice. In a Service that uses version-aware legal materials, legal-acceptance evidence, organization-managed access relationships, public or semi-public verification surfaces, provider-supported delivery systems, and jurisdiction-sensitive rights handling, update mechanics need to be described with more care than a simple statement that the policy may change from time to time. This section should therefore be read together with the legal-acceptance evidence section, the rights and jurisdiction section, and the communications section. It is meant to preserve a serious, version-aware, operationally realistic closing structure for the Privacy Policy rather than a generic tail clause.

22.2 Material versus non-material changes and different update categories

Not every update to this Privacy Policy is the same. Some changes may involve clarifications, corrections, formatting improvements, contact-detail adjustments, provider-category updates, or other administrative refinements that do not meaningfully alter the overall privacy posture being described. Other changes may be more substantive, including changes to how GeriPay describes information categories, processing purposes, disclosure paths, provider dependencies, retention practices, rights handling, incident posture, or other significant operational realities. The fact that GeriPay distinguishes between different categories of changes does not mean that less visible changes are unimportant, but it does mean that notice, timing, prominence, and user-facing process may reasonably vary depending on the nature of the change, the audiences affected, the legal obligations involved, and the practical manner in which the change interacts with the Service.

22.3 Notice methods, audience differences, and organization-managed delivery paths

Where appropriate or legally required, GeriPay may communicate updates to this Privacy Policy through one or more methods, including in-product notices, legal-page updates, account notices, email, workspace-facing communications, notices to relevant organization contacts, or another method GeriPay reasonably considers appropriate under the circumstances. Different audiences may receive different notice paths. A direct account holder, an invited user, an organization-managed workspace participant, a public-site visitor, a verification-surface viewer, or a person submitting a privacy request may not all encounter the same notice channel or the same operational context. In some cases, notice may be delivered primarily through the Service itself. In other cases, organization-managed access structures, designated workspace contacts, or account-linked delivery channels may be more appropriate. GeriPay does not promise that every update will be communicated through the same method, to every person, at the same time, or with the same level of prominence.

22.4 Last-updated dates, effective dates, version identifiers, and archived prior versions

This Privacy Policy is accompanied in its current visible form by a Last updated date and an Effective date of April 28, 2026. GeriPay may also maintain a version reference, archived historical references, or other document-state markers that help explain when a policy text became relevant and how it relates to other legal-document records in the Service. GeriPay may maintain historical references, archived copies, or other version-aware records so that later questions about prior disclosures, policy timing, or legal context can be evaluated against a more stable historical record rather than only the text currently displayed. These document-state markers are also relevant to the broader legal-acceptance evidence system described elsewhere in this Privacy Policy. The visible policy page may not always expose every internal evidence layer or archival reference, but GeriPay may still preserve version-aware records that help establish what policy text existed, when it was active, and how it related to the broader legal-document environment at the relevant time.

22.5 Continued use, acknowledgment, re-review, and re-consent flexibility

Depending on the nature of the update, the applicable law, the user relationship, and the legal mechanics used by the Service at the time, GeriPay may treat continued access or use as relevant to post-update acknowledgment to the extent legally permitted and contextually appropriate. In other situations, GeriPay may instead require or request renewed review, a fresh acknowledgment step, updated electronic-record consent, or another form of re-consent or version-aware interaction before continued use of some or all Service functions. Organization-managed contexts can complicate that process because access may be mediated through an organization relationship rather than through a purely direct consumer-style account. GeriPay therefore preserves flexibility to use different update-handling mechanisms for different categories of changes and different user relationships, rather than promising one universal continued-use or one universal click-through model for every future policy revision.

22.6 Jurisdiction-specific notice obligations, supplement mechanics, and legal-variation handling

Update practices may also vary by jurisdiction, legal trigger, user location, processing context, or applicable regulatory framework. Some laws may require more specific disclosures, more prominent notice, different timing, different rights explanations, or more targeted follow-up after certain categories of changes. GeriPay may therefore provide region-specific notices, jurisdiction-specific supplements, or more tailored explanations where appropriate. Those supplements may clarify, expand, or qualify the main Privacy Policy for a specific legal context without requiring the base document to become a rigid, globally exhaustive compliance chart. This flexibility matters because the same Service can involve organization-directed processing, GeriPay-controlled operational processing, public verification surfaces, provider-supported infrastructure, and preserved evidence layers that do not fit a single universal notice rule in every jurisdiction.

22.7 Contact channels, rights requests, and policy questions after updates

If you have questions about this Privacy Policy, about an update to it, or about a privacy request relating to the Service, you may contact GeriPay at privacy@geripay.com. Unless GeriPay later designates a different channel through updated legal materials, GeriPay currently uses that address for privacy questions, rights requests, support questions tied to privacy matters, and general legal-material inquiries. Some inquiries may be handled directly by GeriPay. Others may need to be routed first to the organization that manages the relevant workspace, especially where the question concerns organization-directed visibility, internal workflow governance, or records the organization controls in the ordinary course of its use of the Service. Support questions, technical troubleshooting issues, reimbursement workflow disagreements, and formal privacy-rights requests are not always the same type of inquiry and may require different routing, different verification steps, or different handling timelines. This Privacy Policy therefore closes with a practical but realistic rule: GeriPay will maintain channels for privacy-related questions and requests, but response paths may vary depending on who is asking, what record family is involved, what legal framework applies, and whether the matter concerns organization-managed activity, GeriPay-controlled operational processing, or both.