IntegrityPhase Privacy Notice
Version 1.7.0_2026-10-14 | English | Final
This Notice explains personal data processing in company onboarding, declared authority, API and MCP use, USDC payments, invoicing and support. It accompanies the English Terms and framework DPA for supported EU businesses, including sole traders and business partnerships. Acknowledging the Notice is not consent to unrestricted processing. Updated on 14 October 2026. This Notice applies to the processing it describes when that processing takes place; finalisation is not evidence that sales or a deployment have been activated.
1 Controller and contact
Marcin Podskarbi, trading as Marcin Podskarbi Prototype 1/2 Lab, NIP 6222767998, REGON 545123210, Rolna 18A, 62-002 Suchy Las, Poland, is the controller for the Operator's own business, security and accounting purposes. Contact privacy@integrityphase.com for privacy and rights, contact@integrityphase.com for general matters, and support@integrityphase.com for support.
No data protection officer has been appointed. The Operator documents and periodically reassesses whether appointment is required, particularly when the nature, scope or scale of processing changes.
2 Roles and categories
The Operator controls personal data needed for the B2B relationship: contacts and the selected invoice delivery details, company and tax data and necessary qualification evidence insofar as they identify people, Delegation issuer and authority basis, Agent identifiers, public keys or fingerprints, Wallet addresses, scope, limits, validity and revocation, signatures and acceptance evidence. Legal person information that identifies no natural person is not personal data merely because it describes a company.
The Operator also processes request and Operation IDs, source identifiers, statuses, timestamps, technical metadata, hashes, connection IP and user agent where needed for security, and support, complaint and incident correspondence. Hashes and pseudonymous addresses can be personal data; they are not automatically anonymous.
Payment records include payer, pay_to, facilitator, native USDC token and Base network, amounts and atomic amounts, quoted exchange rate and time, transaction hash, settlement status and time, refund or correction references. Historical EURC records retain their original token. Invoice records include company details, invoice number, FA(3) hash, KSeF session, number and status, UPO, the verification link, readable invoice and delivery acknowledgement.
Where a customer's lawful Payload or associated metadata contains personal data processed solely on its instructions, the customer is controller and the Operator is processor under the DPA. DPA acceptance is required for every automatic onboarding, including a declaration that no personal data is expected. It does not itself establish the customer's lawful basis or permit additional data categories.
3 Sources and qualification
Data comes from the Agent or person preparing the Delegation in the company's declared name, correspondence, the installed company registers and VAT sources, VIES, the public Base network and configured payment services. The common EU business profile uses VIES and associated identity data, or independently checked alternative evidence in the documented supported cases. National register data remains available for legacy profiles or a necessary independent evidence check; a national registration number is not required from every EU buyer. The system records each check's source, date, outcome and evidence reference.
The French profile relies on a signed declaration of authority. It verifies the declaration signature and binding, key control, scope, limits, validity and revocation, but does not independently verify the issuer's identity or right to represent the company. Records explicitly use authority_model=declared and issuer_authority_verified=false. Registry presence, a valid VAT number and a Wallet signature do not independently establish representation. No representative national identity number or qualified certificate is collected for that purpose in this model.
Required data is necessary for qualification, the agreement, the Buyer Binding, service performance, payment and invoicing. Missing or inconsistent data results in automatic refusal. A temporary registry outage causes bounded retries and a waiting state, not approval. Required VIES evidence cannot be replaced by an unchecked document. Other country rules remain unchanged.
These rules determine business access against objective service conditions, not personal characteristics or an individual's creditworthiness. The system is not intended to make decisions with legal or similarly significant effects on natural persons. A person may request an explanation, correction or submit views at privacy@integrityphase.com; doing so does not create a manual bypass of company, signature, DPA or VAT controls.
4 Purposes and legal bases
For personal data of company contacts, issuers and representatives, onboarding, contractual administration, signature and scope verification, service records and complaints rely on legitimate interests under GDPR Article 6(1)(f): maintaining the company relationship, securing access, documenting instructions and preventing impersonation and abuse. Where the contracting party is a natural person, necessary contract data is processed under Article 6(1)(b). That basis is not used merely because an employee or representative of a different contracting party is named.
Tax verification, invoices, KSeF, accounting and required notifications rely on legal obligations under Article 6(1)(c), including applicable Polish VAT, income tax and tax procedure rules and GDPR Articles 33 and 34. Technical payment processing, reconciliation, continuity and evidence of settlement also serve legitimate interests under Article 6(1)(f).
Necessary security logs, technical check records, acceptance and Delegation evidence and protection against specific claims rely on Article 6(1)(f), subject to necessity and balancing. Customer controlled Payload data is processed on the customer's lawful basis and documented instructions under Article 28 and the DPA. The DPA is not a substitute for that basis.
5 Payload and minimisation
Onboarding must contain no business Payload, sample or attachment. Submit only the minimal identifiers and data needed for webhook_integrity.v1. Prohibited Payload data includes special category, medical, children's and criminal conviction data, secrets, private keys, seed phrases, raw API keys, raw payment signatures, malware and unlawfully processed data.
Production controls must validate current DPA acceptance, Delegation, scope, expiry, revocation and company, Agent, Wallet and source binding before the application reads the body, and repeat the checks after receipt. Body dependent source signature verification occurs after reading. Network infrastructure, the operating system and the HTTP intermediary terminating TLS may receive bytes earlier; an application gate does not erase that infrastructure boundary.
Raw Payload and protocol payment signatures are transient. The application releases references and clears byte buffers it controls after completion, refusal, timeout or failure. Managed strings and objects are subject to memory management; this does not guarantee physical erasure of every process or system memory copy. Raw Payload is not retained in application admission configuration, databases, logs or backups. Persistent records use required identifiers, status and hashes. A future change to persistent Payload storage requires a prior purpose, lawful basis, defined scope and retention, updated documents and notice.
6 Recipients and infrastructure
Authorised personnel receive only necessary access. The Operator's own database and backups are local in Poland. The dashboard remains private and is not a customer portal. No exclusively EEA processing claim is made for the complete service.
Cloudflare, Inc., USA provides DNS and the HTTP Tunnel intermediary. The intermediary terminates TLS and may process onboarding content, Payloads, responses and x402 signature headers. It is a processor for the Operator's controller data and a subprocessor for customer entrusted data within its DPA; its role is not limited to DNS metadata.
Coinbase Developer Platform receives payment authorisation and settlement data, not raw business Payload. Applicable CDP terms cover Coinbase, Inc., Coinbase Crypto Services, LLC and relevant service affiliates. For EEA End User Data within those terms, the Operator is controller and Coinbase is processor. Base is a public network; RPC services receive network queries and connection metadata, not business Payload. The Safe recipient contract is not a separate processor. Kraken supplies public USDC/EUR market data for quoting; the rate request does not require customer company or Payload data.
INSEE, installed national company and tax registries and the European Commission's VIES service receive the identifiers needed for the relevant query. MF and KSeF receive legally required invoice and authentication data. Registry and KSeF interactions are separate from Payload verification.
Proton AG, Switzerland provides correspondence and limited Operator alerts under its applicable DPA and privacy terms. SMTP transport TLS does not imply end to end encryption. Alerts must contain no Payload, secrets or invoice. TaxCoach sp. z o.o., Poland, KRS 0000653979, NIP 7792455049 provides accounting under agreement A_2189 of 4 August 2026 and its processing agreement, without raw Payload. Its agreed Google Drive document workflow involves Google LLC, USA, as the Google Workspace provider identified in the accounting agreement. This does not imply that every accounting subprovider receives every IntegrityPhase record.
Competent authorities may receive data required by law. Standard provider terms do not establish individually negotiated retention or a guaranteed EEA location. New providers or purposes require the relevant notice, lawful basis and DPA change procedure.
7 International transfers and public ledger
For covered Cloudflare transfers to the USA, the EU US Data Privacy Framework adequacy decision applies. Transfers outside that coverage use the relevant safeguards in Cloudflare's DPA, including SCC module 2 when the Operator is controller and module 3 when it processes customer data. For applicable CDP transfers without adequacy, its standard terms incorporate SCC module 2. Transfers to Proton in Switzerland use the applicable adequacy decision; onward transfers require the safeguards in its DPA. Google Workspace in the accounting chain uses applicable DPF coverage or the appropriate SCC under its Cloud Data Processing Addendum. No specific region for the TaxCoach folder is asserted.
Provider terms, subprocessor lists and applicable safeguards are available at cloudflare.com/cloudflare-customer-dpa, coinbase.com/legal/developer-platform/terms-of-service, proton.me/legal/dpa and workspace.google.com/terms/dpa_terms.html. Ask privacy@integrityphase.com for a free copy of safeguards and relevant annexes or an explanation for a specific flow. Other people's protected information or trade secrets may be redacted without withholding meaningful protection information.
USDC and historical EURC transaction addresses, token contract, amount and transaction hash on Base may be public and persistent. The Operator cannot delete blockchain entries and does not custody customer funds. Avoid putting personal or confidential business content on the ledger.
8 Retention
Unsuccessful onboarding and contact data is retained for 12 months after contact ends, longer only for a specific documented duty or claim. Company, Delegation, signature, contractual and acceptance evidence is retained during the relationship and three years from the end of the year in which it ends, unless a specific obligation or proceeding requires longer.
Operational metadata, prepayment decisions and the technical audit trail are retained for 36 months after completion of the Operation or refusal. Credential metadata is retained for 24 months after revocation. Ordinary security and error logs are retained for 90 days; necessary logs for a documented incident remain until closure and for 36 months afterwards. Support, complaint and incident case data remains until closure and three years from the end of that calendar year.
Invoices, accounting records and necessary settlement and exchange rate evidence are retained for five years from the end of the calendar year in which the tax payment deadline expired, or longer where a statutory suspension, interruption or special rule applies. Merely linking a technical record to payment does not make all of it accounting evidence. The Operator's own income tax status is not changed by this Notice or by USDC payment.
Raw Payload and payment signatures remain only transiently as described above. Entrusted active data is deleted or returned without undue delay and within 30 days after processing of its category ends, with shorter periods taking priority. Backup copies expire within a maximum 30 day rotating cycle and remain isolated from ordinary processing pending expiry. Deletions and restrictions are reapplied before ordinary processing resumes after restoration; restoration does not restart retention.
Specific documented duties, incidents or claims may justify retaining only necessary data, with necessity and scope reviewed at least every six months. Once the purpose and basis end, data is deleted or effectively anonymised. Hashing alone does not anonymise. Deleting a hosted Proof copy prevents later retrieval from the service but does not prevent independent verification of a customer's retained copy or authorise charging the same order again. Public ledger retention follows the network and is outside the Operator's deletion control.
9 Rights and cookies
Subject to GDPR conditions, people may request access, rectification, erasure, restriction, portability, object to processing and withdraw consent where consent is the basis. Contact privacy@integrityphase.com. Proportionate identity and scope information may be required. Requests concerning data processed solely for a customer are passed to that customer or supported under the DPA. Complaints may be made to the Polish supervisory authority, the President of UODO, or another competent authority under GDPR.
The current service uses no analytics or marketing cookies. Any cookies needed for security, sessions or essential operation are limited to that purpose. Introducing analytics, marketing or other tracking requires updated notice and consent where applicable.
10 Security and changes
Before processing production data the Operator implements proportionate access and revocation controls, least privilege, TLS, protected credentials, environment separation, integrity and audit records, incident response and controlled backups. Secrets and private keys are excluded from logs and audit evidence. No system guarantees that incidents cannot occur. Uncertain payment outcomes are reconciled without an automatic second charge.
Material changes in law, providers, data, payment or functionality are notified electronically and may require renewed acknowledgement before further use. Previous versions and presentation evidence are preserved under the applicable retention rules. Internal alerts are not notifications to affected persons, customers or authorities; those need the appropriate recipient and evidence of delivery.
EU business qualification and agent applications
Business contact and billing data may be personal data for a sole trader. Necessary identification and contract data is processed for contract performance where the data subject is the contracting party, legal duties for tax records, and the applicable legitimate interests for representative and security information, as described above. Required qualification fields have a documented purpose; national register fields are not collected for every buyer by default. Qualification evidence distinguishes data declared by the Agent from independently confirmed name, address and business or tax status. VIES receives only the identifiers needed for the query; an alternative identity check may require the corresponding necessary name and address. Company data is sent to IntegrityPhase and necessary verification/accounting services, not to the blockchain or unnecessarily to payment intermediaries. Private signing keys stay with the customer application. Prepared authority and source references do not authorise disclosure of the underlying secrets to the model.
The existing Coinbase channel and authenticated invoice delivery remain subject to the above data flows. Nevermined is not represented as an active recipient or processor before its actual integration and applicable privacy information have been assessed and presented. New material processing purposes or providers require prospective notice and the applicable acceptance process; historical acknowledgements are not rewritten.