What the extension checks, sends, and deliberately leaves in your inbox.

Who is responsible

For an employer deployment, the customer is the controller for employee and mailbox processing. FIT PUP LTD (PayHQ) acts as processor on the customer's documented instructions under our Data Processing Agreement. The customer selects users, mailboxes, operating mode, retention and optional providers, completes its lawful-basis and employee-monitoring assessment, and gives employees advance information.

Our general Privacy Notice covers our own website/account-side controller processing. This page covers the extension-specific processor path.

Single purpose

The extension's single purpose is to give selected AP and finance users advisory warnings about suspicious supplier, payment and link indicators in supported business webmail. It does not decide that an email is safe, block or delete mail, approve payment, change supplier records, score employee performance or make employment decisions.

Local inspection and the transmission gate

When a supported message is opened, the extension performs bounded local inspection for fixed fraud indicators. Most messages send nothing to PayHQ and create no PayHQ scan event. A request is sent only when an approved local trigger fires or inspection reaches a declared safety limit and cannot reliably classify the message locally.

Local inspection can examine bounded parts of the visible sender, message text, links and attachment metadata. That is still handling personal communications even when the original content remains on the device, which is why the first-run disclosure and this policy cover both local and server processing.

Data sent after a trigger

A triggered request may contain only structured, bounded fields:

• Bound work-mailbox address, mailbox provider, a provider-scoped message identifier, and user/device attribution.
• Sender address; normalized domain, link and lookalike indicators; opaque supplier/alias candidates; and fixed trigger/reason codes.
• Typed payment candidates such as IBAN, Bankgiro or Plusgiro for server-side comparison with the customer's independent supplier registry.
• Fixed phrase flags, attachment extensions/reasons, declared local-limit flags, and rule-pack/registry versions.
• The verdict, fired rules and immutable decision/provider snapshot needed to explain and reproduce the advisory result.

Depending on customer configuration, the client can hold a short-lived workspace set of trusted domains and supplier names/aliases for local comparison. It never receives saved supplier payment methods or supplier contact addresses. A server-side-only mode avoids syncing the supplier set, with reduced local coverage.

Data the scan function does not send or retain

• Message subject, body, snippets or quoted history.
• To, Cc or Bcc recipient lists.
• Raw sender display name, raw headers, MIME or inbox HTML.
• Attachment names, bytes, previews, hashes or extracted text.
• Unflagged links, unsanitized URLs, URL queries/fragments/user information or credential-like path material. A locally flagged reputation URL may transiently include non-sensitive canonical path segments after sanitization; PayHQ stores its digest and host, not the submitted path.
• Saved supplier-registry payment values.

A minimized event is still personal data: the mailbox, provider message ID, sender and user/device attribution can show that a person encountered a triggered message. We do not describe this as anonymous.

Warn and Monitor

Warn displays the advisory result in the inbox. Monitor processes and retains the same attributed event but does not display the inbox verdict. Monitor must be disclosed in advance, limited to a customer-recorded start/end date and used only as a pilot evaluation phase. It is not a permanent silent employee-monitoring mode.

Flagged links and Google Web Risk

The Google Web Risk client and sanitizer are implemented but the provider path is disabled by default and not in production use. If a customer later enables it, only a URL already flagged by the local fraud rules may be sent after canonicalization removes query, fragment, user information and credential-like path material. PayHQ stores the URL digest, host, reason code and bounded provider snapshot, not the submitted URL path or query.

Google Web Risk is listed as a planned provider on our Sub-processors page. It is disabled by default and will not receive extension data before the customer approves that provider path. A provider error or no-match result is never presented as proof that a link is safe.

Retention and deletion

The proposed pilot default is 90 days from scan-event creation, configurable by the customer before collection begins. A shorter period is permitted. A longer period requires a documented necessity and proportionality reason in the customer's DPIA/LIA. Deletion covers indicators, mailbox/message correlation, user/device attribution and decision/provider snapshots.

This is the target contract, not a claim that production retention is already running. Production enablement waits for the scan API to enforce and test the configured value and deletion behavior.

Human access and prohibited use

Individual extension data may be read only for the user's explicit request concerning specific data, a documented fraud/abuse or security investigation, or a legal obligation. Aggregated and anonymized data may be used for service operations where individual data is unnecessary. Customer administrators must be limited to named fraud/security roles and case-linked access.

We do not use or transfer extension data for advertising, data-broker sale, unrelated profiling, creditworthiness/lending, employee productivity or disciplinary monitoring. See our Limited Use statement.

Your controls and separate uploads

Before first collection, the extension must disclose its purpose, data categories and provider sharing and require an affirmative user action. It must also provide a setting that immediately stops new extension collection, including for a managed installation. That action is a transparency and browser-store control; it is not represented as the employer's GDPR lawful basis. The employer must explain its lawful basis and objection/rights process in its employee notice.

Sending an invoice attachment to PayHQ is separate from background scanning. It requires a user-selected attachment and a per-action disclosure; scan permission never authorises a general email-content upload.

Security incidents, rights and contact

We notify the customer of a personal-data breach under the DPA. The customer handles employee and third-party data-subject requests and supervisory authority/data-subject notification decisions; we assist with information available to us. A breach involving financial/payment or authentication data also follows applicable browser-store notification requirements.

For a deployed workspace, contact the employer/controller named in its employee notice first. PayHQ privacy questions can be sent to [email protected]. We update this page before materially changing the purpose, data categories, trigger frequency, providers, retention, mode behavior or human-access rules.