Data Processing Agreement

The Customer is the data controller of any personal information they upload to or instruct MarginShield to process. MarginShield is the data processor, acting on documented instructions from the Customer.

MarginShield acts as an independent controller, not as a processor, for account data and for what BAFO for Shopify records about the Customer's staff when they install BAFO or sign in to it through Shopify, as the Privacy Policy's Section 2 (“The merchant's own data”) describes: MarginShield decides why and how that data is used, to run the Customer's account, keep its security record and limit how many stores one person can connect.

“Personal information” carries the meaning given in the Australian Privacy Act 1988 (Cth) and, where applicable, the EU General Data Protection Regulation (GDPR).

MarginShield processes the following categories of data strictly for the purpose of delivering the Service:

• Account data: user name, business email address, role, organisation name. Where BAFO for Shopify creates the account when the Customer installs it: the name Shopify gives for the installing staff member (or, if none, the store's name) and the email address Shopify has verified for them. An unverified address is neither looked up nor stored; on a first install, the account instead has an undeliverable sign-in address and no contact address, and is bound to that store and Shopify user ID. The organisation's audit log records the Shopify user ID, whether they own the store or are a collaborator, and later sign-ins from the Shopify admin. Refused attempts contain no Shopify user ID, email or hash of one.
• Business data: product catalog, cost structure, supplier agreements, competitor observations, approval decisions, audit events.
• Usage data: authentication logs, application events, error and performance telemetry — used for service operation and security only.
• BAFO for Shopify shopper and order data: where the Customer installs the optional BAFO for Shopify feature: for each offer request a shopper submits, the shopper's chosen reason and answers (including any competitor and price they give); the storefront context (currency; whether the shopper is logged in; the product on the page and any add-on product the Customer suggests, each with its product and variant ID, product and variant title, price and availability; and the cart's total, item count and each line's product ID, variant ID, quantity and price), with no storefront country (requests stored by earlier versions can hold it until they are deleted); a keyed hash (HMAC) of a logged-in shopper's Shopify customer ID, never the ID itself, which in request-collection mode is used to find the shopper's requests for Shopify's data and deletion requests, and where automatic offers are enabled is also used for eligibility, overlapping-offer checks and binding the offer to the shopper; keyed hashes of the cart token and of the request, never the token itself; and the response and the Customer's review record. No IP address. The request logs Vercel and Railway keep as hosting providers can include the IP address a request came from and the customer ID Shopify adds for a logged-in shopper; Vercel keeps them for at most 30 days and Railway for at most 90 days, depending on plan. When the Customer enables bounded decision ranking, BAFO can also process one optional shopper-authored clarification of at most 280 characters. Anthropic receives only the selected reason, that optional clarification, opaque identifiers for the current request's non-monetary candidates, fixed response template identifiers, action-type, explanation and capability-status codes, and bounded ordinal ranking values. The adapter supplies no structured shopper or customer identity, passive behaviour or hesitation score, product or cart identifier, system price, merchant cost, margin floor, budget, monetary candidate or offer amount. The optional clarification is free text and may contain personal information or a price the shopper chose to enter. It selects among server-owned fixed response templates and does not generate shopper-facing text or calculate an offer. Bounded cart-behaviour signals and a 0–100 hesitation score, collected only with the shopper's analytics consent and only when the Customer switches on the cart prompt (off when the BAFO block is added), used to decide whether the automatic invitation may open (which also requires the shopper's marketing consent) and to help the Customer's review team, and never to set, change or influence a price. In the default review-only mode, native order and refund facts, only for test orders linked to a BAFO request by the shopper's cart, in a store whose currency is AUD, EUR, GBP, NZD or USD: the order's ID, name, test flag, currency, financial status and last-updated time, its total price and total refunded, and each refund's ID and total, read from Shopify, with no customer, contact, address or note fields and no line items. They are kept so the Customer can see on its BAFO Orders page whether each such order was paid, cancelled or refunded, so a later refund or cancellation of the order is recognised, and so a customer's records can be found for Shopify's data and deletion requests. Shopify sends the order created, paid and cancelled notifications only for test orders, trimmed to the order's ID, test flag, cart token and last-updated time, and sends a refund notification for every refund, trimmed to the refunded order's ID and the refund's ID; the last-updated time and the refund's ID only stop Shopify discarding a later notification as a copy of an earlier one, and are not used. For a test order that is not stored, only the reason it was not stored and the time, for the Customer's BAFO Orders page, replaced by the next and deleted on uninstall. Full detail in the Privacy Policy.

BAFO for Shopify uses the store’s saved settings: shoppers may submit requests, automatic offers run only where enabled for the store, and merchant fees apply only when disclosed and enabled.

Review-only service is the default. The Customer can later give a separate instruction to run a measured offer experiment for a particular store and for either test or live orders. Processing for that experiment starts only while an active certificate records a current owner or admin's agreement to this September 21, 2026 DPA and Privacy Policy, the store's current installation, a granted and verified read_ordersscope, verified order notifications and retention job, and the exact active experiment. Live-order processing also requires Shopify's protected customer data approval. Reinstalling the app, withdrawing that instruction, removing the scope, disabling the consenting person, stopping the experiment or switching off collection closes the gate. Test facts are never relabelled as live facts.

In an active measured experiment, MarginShield records an eligible exposure and stable treatment or control assignment on the server before an invitation can be shown. It records the experiment and policy versions, surface, currency, item and variant counts, eligibility and outcome-window times, and keyed hashes of the cart and, for a logged-in shopper, customer ID; it never records either raw identifier. Control assignments, ignored invitations and eligible shoppers who do not buy remain in the denominator, with later invitation, selection, issue, application, checkout, payment, cancellation, refund, complaint and repeat-order events recorded when they occur.

For a measured test or live order, MarginShield stores its immutable environment, order and event IDs, revision time, financial and cancellation status, tax-inclusion and edit status; received, refunded and retained payment; subtotal, discount, tax, shipping, duty, fee, tip and total amounts; line product and variant IDs, ordered, current and refunded quantities, original amount, discount allocation, current price after all discounts and before tax, and line taxes; and refund totals, lines and shipping. It still requests and stores no customer, name, email, phone, address or note field. Duplicate notifications are recorded once and cumulative revisions move only forward, including when a refund arrives before a paid notification. Merchant-supplied cost components remain unknown until an authoritative source supplies every required value; incomplete or non-conserving financials remain provisional and produce no uplift or commercial decision.

The primary analysis cutoff is fixed separately for each eligible exposure. Shopify's order-created time determines whether an order is inside it, even when the notification arrives later. A later refund or cancellation of the same in-window order updates its provisional or complete state. A new order created after the cutoff is retained and labelled only as a later relationship fact, has no primary maturity date and does not alter the primary result. Every sourced cost and fee revision is bound to an exact cumulative order snapshot; carry-forward requires an explicit new matching revision that names an earlier snapshot.

BAFO for Shopify processes no shopper request for a store, and so no order facts (kept only for orders linked to a stored request), until an owner or admin of the Customer's BAFO workspace has agreed there to this DPA and the Terms of Service for that store, having been shown the Privacy Policy. Until then every request from that store receives a neutral “unavailable” answer and nothing is stored. MarginShield records who agreed, when, and to which versions of the three documents.

MarginShield does not knowingly process sensitive personal information (health, biometric, political, religious data) and the Customer agrees not to upload such data.

For BAFO for Shopify shopper and order data specifically: the Customer (merchant) is the data controller of their shoppers' data and MarginShield is the data processor, acting only on the Customer's instructions to run the feature as configured. MarginShield deletes this data automatically, in a scheduled deletion job, once it reaches these limits: offer requests, and the entitlements issued from them, 90 days after the request (a request whose entitlement is still live is kept until that entitlement expires); customer eligibility records when they expire or after 90 days without being refreshed, whichever is sooner; and order and refund events, and records of uninstall and compliance notifications, 400 days after they arrive; measured order receipts, snapshots, line and refund components once the order was last observed more than 400 days ago and its outcome window has matured; measured exposure and assignment records once their outcome window matured more than 400 days ago and no measured order still depends on them; and customer data requests 90 days after they arrive, whether or not they were answered. Bounded reasoning operational records (the provider, model and adapter version, configuration revision, opaque context and candidate-set hashes, status, token and latency totals, estimated cost, or a bounded failure code) are deleted after the same configured offer-request period. They contain no clarification, prompt, provider response or merchant-private economic facts. These default periods can be changed only within fixed limits (31 to 365 days for offer requests and eligibility records, and 90 to 730 days for order and refund events), and automatic deletion cannot be switched off; a deleted record leaves encrypted backups as set out in Section 9. The deletion job runs at the start of MarginShield's regular scheduled run, before and separately from the other work in it, so neither can stop the other, and it is also scheduled on its own. Uninstalling the app immediately clears the store's Shopify access and refresh tokens, revokes its offer entitlements and stops all collection, but deletes no shopper data itself. Shopify's shop-redact request, sent 48 hours after the app is uninstalled, deletes the store's offer requests (with their entitlements), customer eligibility records, customer data requests, measured exposures and order outcomes, and Shopify events, except the records of the uninstall and of the shop-redact request; if the store has been reinstalled since the uninstall, it deletes only those collected before the reinstall, and the reinstalled store stays connected. Shopify's customer-redact request deletes the customer's eligibility records, offer requests and open customer data requests (found by the keyed hash of their Shopify customer ID, which every request they made while logged in carries) and, for each listed order that BAFO stored, that order's events and the offer requests made from its cart. In default review-only mode, BAFO stores only test orders linked to a request, never a real order, so an offer request made while the shopper was not logged in cannot be found through a real order by either request; it is deleted when its retention period above ends. For an explicitly authorised measured live experiment, BAFO also deletes the listed live order outcomes, receipts, lines and refunds, and the eligible exposure linked by the customer hash or those orders. Shopify's customer data request is answered through the Customer: MarginShield counts the customer's stored offer requests, entitlements, eligibility records and listed orders' events, found the same way, and, for a measured experiment, the customer's matching eligible exposures and listed orders' measured outcomes. It deletes nothing. If there are none, the request is resolved at once and nothing that identifies the customer is kept. If there are any, the request is kept open holding nothing about the customer except its keyed hash and the IDs of the listed orders whose events are held, the Customer's owners and admins are emailed a notice that names no customer, and they download the records from the BAFO workspace and mark the request as sent, which deletes that hash and those IDs. The notice gives the store, when the request reached MarginShield, the deadline 30 days after that, the record counts and a link to the workspace, and is retried on the scheduled runs, up to six attempts, if no owner or admin can be emailed. Only the Customer's owners and admins can download the records, as a JSON file that includes each request's hesitation score and the Customer's review of it (outcome, time and any note) and leaves out every keyed hash, the reviewer's identity, the rest of the Customer's decision record and entitlement discount codes and signed tokens, including any discount code in a stored offer response. For a measured experiment the file also includes the matching exposure timeline and listed orders' financial snapshots, lines and refunds, and leaves out the Customer's private cost, fee and support-source records; a request can be marked as sent only after a download, and MarginShield never contacts the customer. If an owner or admin cannot download the records, the Customer can ask privacy@marginshield.io for help reaching the download; MarginShield never sends the records themselves by email. This data is processed only by the sub-processors named in Section 3 that carry or store it for this feature (Vercel, Railway, Neon, Anthropic and Sentry). It is never sold, never shared with any other third party, and never used to train external foundation models.

Optional local policy learning requires the Customer's explicit delegation. It uses the Customer's existing BAFO experiment assignments, fixed response choices, linked purchase and refund outcomes and complete contribution facts to evaluate non-monetary response templates. Ignored invitations and non-buyers remain in the comparison. The learner runs inside MarginShield and sends no records to an external model provider; it cannot expand financial permissions. Disabling it restores the fixed baseline for future decisions. Shopper-linked learning decisions and assignments follow the underlying exposure's retention and erasure rules. Derived strategy and evaluation artifacts retain identifiers, hashes, aggregate scores, counts and audit results without raw shopper or order payloads until the associated installation or organisation is erased.

Shared learning is off by default and requires separate, versioned, expiring owner consent specifying permitted features, clipping and contribution limits. Only aggregate counts and clipped scores with policy and lineage hashes enter MarginShield's pooled database. No customer, cart or order identifier, raw cost or individual reward is contributed, and the aggregate reader returns no merchant identity. Withdrawal, expiry or an installation-authority change removes the contributed aggregates through the bounded retention process; only deletion counts and an irreversible lineage receipt remain. A shared candidate requires tenant-local evaluation before activation. Turning learning off does not erase audit history.

MarginShield uses a limited set of sub-processors to deliver the Service. The current list:

• Vercel (USA / global edge network) — web application hosting, including app.bafo.io, which receives every BAFO for Shopify storefront request and Shopify notification and passes it to the API.
• Railway (USA / global) — application hosting and managed Redis.
• Neon (Singapore, ap-southeast-1) — managed Postgres database.
• Cloudflare (R2 object storage, global) — only when large-file catalogue import is switched on: the catalogue CSV files the Customer uploads for import, read back once by the importer. No BAFO for Shopify shopper or order data.
• Stripe (AU/global) — billing and payment processing. Card data is tokenised; MarginShield never stores card numbers.
• Anthropic (USA) — bounded selection among server-owned, fixed, non-monetary BAFO response templates. It receives the shopper's selected reason, an optional bounded shopper-authored clarification, opaque one-request candidate identifiers, fixed response-template identifiers, action-type, explanation and capability-status codes, and ordinal ranking values. The adapter supplies no structured identity, passive behaviour, product or cart identifier, system price, merchant cost, margin floor, budget, monetary candidate or offer amount. The optional clarification is free text and may contain personal information or a price the shopper chose to enter. Anthropic supplies no shopper-facing prose. Margin and offer calculation remain deterministic and are never delegated to a model.
• Sentry (USA) — error monitoring of our API, and performance tracing for a sample of its requests (10% in production); the web application sends nothing to Sentry. Request bodies, cookies, query strings, IP addresses, User-Agent strings and every request header except Accept, Content-Type and Content-Length are removed from error reports and performance traces before transmission, and every other detail recorded about a traced request, or a step in handling it, is dropped unless it is on a fixed list of safe technical facts (such as the method, response status, route and sizes); a database or cache step keeps only its first word, and no line the API writes to its own log is sent.
• OpenAI (USA) — text embeddings used to match products: the names, brands, categories and barcodes of the Customer's products and of monitored competitor listings. No personal information is sent.
• Resend (USA) — transactional email delivery.
• Twilio (USA) — SMS alerts the Customer sets up: the recipient's phone number and the alert text.
• Bland AI (USA) — voice price-discovery calls the Customer starts: the competitor store's business phone number, the product and competitor names, and the call's transcript (no audio is recorded), which can contain whatever the person who answers says.
• Google (global) — the Places service, to find a competitor store's public business listing and phone number for a voice price-discovery call.
• Firecrawl, Scrapfly, Zyte, Jina AI and SerpAPI — retrieval of public competitor web pages and search results for the products the Customer monitors. They receive public page addresses and product search terms only, never personal information or BAFO for Shopify shopper or order data.
• PostHog (USA by default) — product analytics of the web application's page views, when switched on: each page's web address (for the BAFO for Shopify install pages, including the store's myshopify address) and browser and device type, under a random identifier; and, from the API, an event when an organisation reaches its plan's product or competitor limit, identified only by the organisation, with its plan and counts. MarginShield never sends PostHog a user's name or email address, or any BAFO for Shopify shopper or order data. The analytics runs only while the PostHog project is set to discard client IP data, and asks PostHog not to look up a location.

MarginShield gives the Customer at least 30 days' notice of any new sub-processor by email to the registered Customer administrator, and the Customer may object in writing.

MarginShield engages each sub-processor under a written contract that imposes on it data protection obligations no less protective than those in this DPA, in particular sufficient guarantees of appropriate technical and organisational measures, and remains fully liable to the Customer for each sub-processor's performance of those obligations.

MarginShield maintains technical and organisational measures appropriate to the risk, including encryption in transit and at rest, tenant isolation, role-based access control, append-only audit logging, and incident response. Full posture published at /security.

MarginShield ensures that every person it authorises to process the Customer's personal data, staff and contractors alike, has committed to confidentiality or is under an appropriate statutory obligation of confidentiality, and processes that data only on the Customer's instructions.

The Customer's primary database is hosted in the Asia-Pacific (Singapore) region; application hosting is as listed in the sub-processors in Section 3. Limited transfers occur to the United States and other regions via the sub-processors named there. The Processor is an Australian entity and remains subject to the Australian Privacy Principles in respect of Personal Data processed under this DPA.

Where the GDPR applies to the Customer's personal data and it is transferred to MarginShield, which is established in Australia, a country without an adequacy decision, the Standard Contractual Clauses adopted by the European Commission in Implementing Decision (EU) 2021/914 (the “SCCs”) are incorporated into this DPA by reference and form part of it, the Customer being the exporter and MarginShield the importer of the personal data, in the SCCs' sense of those roles: Module Two (controller to processor) and, where the Customer acts as a processor for another controller, Module Three (processor to processor). For the SCCs: Clause 7 (docking) applies; under Clause 9, option 2 (general written authorisation) applies, with the notice period in Section 3; the optional wording in Clause 11 does not apply; under Clause 17, option 1 applies, with the law of Ireland; under Clause 18, the courts of Ireland; Annex I is completed by Sections 1 and 2 of this DPA, Annex II by Section 4 and the security posture it refers to, and Annex III by Section 3. MarginShield makes onward transfers to its sub-processors only as the SCCs allow, including by entering into Module Three of the SCCs with a sub-processor where no other safeguard or adequacy decision covers the transfer. Where the UK GDPR applies, the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner (version B1.0) is incorporated in the same way, its tables completed from the same sections. If the SCCs or the Addendum conflict with this DPA, the SCCs or the Addendum prevail.

MarginShield will assist the Customer in responding to requests from data subjects to exercise their rights of access, rectification, erasure, restriction, portability or objection. The Customer is the primary point of contact for its own users; MarginShield will action verified requests forwarded by the Customer within 30 days.

Taking into account the nature of the processing and the information available to it, MarginShield also assists the Customer in meeting its obligations on the security of processing, notifying personal-data breaches to supervisory authorities and to data subjects, data protection impact assessments and prior consultation with supervisory authorities (GDPR Articles 32 to 36), including by providing the information in this DPA, on the security page and, on request, any further information it holds that the Customer reasonably needs for them.

MarginShield will notify the Customer of a confirmed personal-information breach affecting the Customer's data without undue delay, and in any event within 72 hours of confirmation. Notification will include the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and the measures taken.

On reasonable written request and no more than once per year, MarginShield will provide a summary of its security controls (and, if we later obtain them, SOC 2 / ISO 27001 attestations) sufficient to demonstrate compliance with this DPA. On-site audits may be performed by a mutually agreed independent auditor at the Customer's cost.

There is no self-service deletion: the Customer asks for it at privacy@marginshield.io. At the end of the Service, MarginShield returns the Customer's personal data or deletes it, at the Customer's choice, and deletes existing copies unless the law requires their storage: the Customer may ask for a copy of their data, or for its deletion without a copy. On termination of the Service, the Customer may request a copy of their data within 30 days. After 30 days, all Customer data is deleted from active systems within 90 days, and from encrypted backups within a further 90 days, unless legal retention obligations require otherwise. Copies held briefly in MarginShield's background job queue (such as an alert's recipient and text, or a catalogue file being imported) are deleted from it automatically, within a day of the job completing, seven days of it failing, or seven days of being queued if it never runs, and the Customer's are removed from it when its account is deleted. What stays in active systems is the Customer's audit trail, which is never deleted: the names, email addresses and hashes of them, phone numbers and Shopify user IDs in it are replaced with “[redacted]”, the IP addresses and browser details recorded with it are cleared, and the organisation and user records it refers to are kept only as suspended placeholders, with the name, email address and password removed. Where BAFO for Shopify created the Customer's account when it was installed, and no one has set a password on it or holds a billing account for it, MarginShield deletes it in this way automatically 30 days after Shopify's shop-redact request for the last store connected to it, unless one of its stores is reinstalled first. MarginShield's own operator log entries about the Customer also stay, with the same values replaced, as does, for a member of a buying group, its clean-room access log (query types and counts only). BAFO for Shopify shopper and order data follows the retention and deletion rules in Section 2, including deletion when Shopify's shop-redact request arrives 48 hours after the app is uninstalled, is also deleted with the Customer's account, and once deleted it leaves encrypted backups within the same further 90 days. Deleting the Customer's account does not uninstall BAFO from the Customer's store.

Privacy and data-protection enquiries: privacy@marginshield.io.

Customers requiring a countersigned DPA on letterhead can request one at legal@marginshield.io.