Privacy Policy

1. Controller and contact

1.1. For the processing described in section 2.1, the controller is BidFinance spółka z ograniczoną odpowiedzialnością, ul. Kącik 4, 30-549 Kraków, Poland, registered under KRS 0000975000, NIP 6793240675, REGON 522206447.

1.2. For privacy matters and rights requests, contact info@bidfinance.pl or write to the address above with the reference “Personal data”.

1.3. No separate data protection officer has been designated. BidFinance’s owner coordinates privacy and incident matters; the contact address is info@bidfinance.pl.

2. Scope and the parties' roles

2.1. BidFinance acts as controller for the personal data it uses to invite and identify Platform users, administer accounts and company permissions, verify authority to represent a Participant, provide service communications, protect accounts and the Platform, and keep proportionate evidence of Platform terms, transactions relevant to its own fees, and legal claims. This does not make BidFinance the controller of all personal data contained in uploaded auction or transaction documents. This Policy also covers our own processing of website-visitor data, professional business contacts and support correspondence described below.

2.2. Where a customer entrusts BidFinance with personal data in portfolio documents, VDR materials or transaction-workspace content for processing on that customer’s behalf, BidFinance acts as processor within the documented instructions and applicable separate Data Processing Agreement. Those instructions govern the authorised operations and recipients, including hosting, document versions, search and any configured text recognition, access permissions and related workflow evidence. The customer determines the purpose and lawful scope of the entrusted processing. If the customer acts on behalf of another controller, the required authorisation and contractual processing chain must be established. BidFinance’s separate use of limited account, security or settlement records does not authorise independent reuse of the entrusted content. This Policy does not replace the customer controller’s notice to debtors or independently authorise disclosure of their data. The separate DPA standard template is provided for review; publication alone does not execute it for a customer.

2.3. We direct requests about entrusted data to the relevant controller and assist it under the data processing agreement. We remain directly responsible for our own controller operations described in section 2.1. Anonymous data that cannot be linked to a person using means reasonably likely to be used must be distinguished from merely pseudonymised data.

2.4. Materials made available to buyers in connection with an Offer must comply with the anonymisation and confidentiality requirements of the Platform Terms. Access to any identifiable personal data in a separate authorised confidential workflow requires an appropriate legal basis, documented instructions and applicable secrecy safeguards. A buyer that lawfully receives personal data and uses them for its own evaluation or acquisition purposes acts as a separate controller for that use. Giving access through the Platform does not itself establish a legal basis for disclosure.

2.5. Capitalised terms have the meanings assigned in the BidFinance Platform Terms and Conditions or Auction Rules. BidFinance employees are internal Platform personnel, not a customer company or its Users.

3. Data sources and how we inform you

3.1. We obtain data from you when you use an Account, write messages, submit bids, sign Portfolio Purchase Intent Confirmations, upload documents, configure authentication or contact us. Technical data and evidence of actions are generated when you use the Platform.

3.2. We also receive business details needed to invite you or administer access from the company you represent, its Account administrator or an authorised person identifying you as a contact. These include your name, business email, company, role and any telephone number supplied. Authorised participants also provide data relating to a particular auction or transaction.

3.3. Where we obtain professional contact details from publicly accessible sources, the source category may include a company website, a public business register or a publicly accessible professional profile, depending on the source actually used. The individual privacy notice identifies the actual source, its URL where available, the date we obtained the data and whether the source is publicly accessible. A publicly available address does not constitute consent to electronic marketing.

3.4. For data obtained indirectly, you will receive the information required by Article 14 GDPR within a reasonable period and no later than one month after collection, or by the first communication with you or first disclosure to another recipient if either happens earlier. An applicable legal exception must be assessed individually. Publication of this Policy alone does not replace individual provision of the information where required.

4. Data categories and whether you must provide them

4.1. Account and contact data: name, business email, telephone number, company, job title or role, permissions, country, language, Account status, invitation details, communication preferences, password hashes and authentication settings. We do not store the Account password in plaintext.

4.2. Activity data: auction participation, bids, Auto-Bid or walkaway settings, offer selections, details of the person signing a Portfolio Purchase Intent Confirmation (including name, email and IP address), transaction milestones, reports, versions and timestamps of accepted legal documents, notifications, read receipts, presence or last activity, and audit records.

4.3. Correspondence and technical data: questions, answers, messages, announcements, support correspondence, file names and metadata, document downloads, IP address, browser information, hashed session identifiers, session times, authentication, email/SMS delivery, file-scanning and diagnostic information. Information about third parties contained in entrusted documents is subject to the role distinction in sections 2.2–2.4.

4.4. Marketing data: business contact details and role, company, source and date of acquisition, contact and campaign history, evidence of required consent, preferences and objections or unsubscribe records.

4.5. To create a customer company User Account, we require the company association, first name and email address. A surname and general contact telephone number are optional at Account creation. A telephone number becomes necessary when the applicable authentication method requires SMS; email authentication does not make a telephone number universally mandatory. Activation requires an individual invitation, a password and its confirmation, acceptance of the applicable Terms and Auction Rules, and acknowledgement of the Privacy Policy. Without the data required for the applicable access method, we cannot activate or authenticate that Account.

4.6. These Account requirements are conditions for providing the service, not a general statutory obligation to have an Account. To answer an enquiry, we need enough information to contact you and understand the matter. Our separate duties to retain applicable accounting and tax records are described in section 5.5. Marketing consent and additional information unrelated to the service are optional; withholding them does not prevent use of the paid service.

5. Purposes and legal bases where we are a controller

5.1. Where you are personally a party to a contract with BidFinance as a Participant, including as a sole trader, we process the data objectively necessary to perform that contract or to take steps at your request before entering into it under Article 6(1)(b) GDPR. Where you act for a company or another entity, we process your representative and contact details under Article 6(1)(f) GDPR for our legitimate interests in verifying authority, managing the business relationship, providing the company’s access to the service and communicating with its authorised representatives. Account security, proportionate claims evidence and statutory obligations are assessed separately for their stated purposes; they do not automatically fall under Article 6(1)(b).

5.2. Account security, abuse detection, access control, session integrity, incident investigation and necessary audit trails — Article 6(1)(f) GDPR; our interest is protecting the Platform, people and information against unauthorised access and abuse. This does not authorise unlimited retention of every event.

5.3. Invitations, password resets, authentication codes and operational Account, auction and transaction messages — Article 6(1)(f) GDPR, in the interest of secure access and performance of the relationship with the company. These messages serve the service and are not consent to marketing campaigns. The separate legal obligations concerning data-rights requests are described in section 5.7.

5.4. For relevant business contacts, we rely on Article 6(1)(f) GDPR to manage professional contact details and promote BidFinance's own services. Our interest is developing business relationships with organisations for which those services are relevant. We use this basis only where the processing is necessary and proportionate and your interests, rights and freedoms do not override that interest. This is separate from permission to send commercial information, including direct marketing, through a particular channel. We send such communications only with the valid prior consent required by Article 398 of the Polish Electronic Communications Law. Public availability of an address, provision of an Account-service address, acceptance of the Terms or reading this Policy does not itself give that consent. You may withdraw channel consent or object to direct marketing at any time without giving a reason, using the unsubscribe option or our privacy contact. Following an objection, we stop processing your data for direct marketing. Necessary Account-service messages are separate.

5.5. Accounting and tax records — Article 6(1)(c) GDPR, where the record is subject to a specific statutory duty. We retain our accounting books and accounting documents under Article 74 of the Polish Accounting Act (consolidated text: Journal of Laws 2026, item 522, as amended), and tax books and related documents under Article 86 § 1 in conjunction with Article 70 of the Tax Ordinance (consolidated text: Journal of Laws 2026, item 622, as amended). The applicable periods and starting events differ by record category; see section 9. We disclose data to an authority under this ground only after establishing a specific binding legal obligation covering that request and the necessary data. These duties do not create a blanket basis for retaining all Account, VDR or debtor data.

5.6. Establishing, exercising or defending claims and preserving necessary evidence of service performance — Article 6(1)(f) GDPR, in the interest of protecting BidFinance's rights. We retain only information relevant to a specific category of claim, under an established retention period or a documented evidence-preservation hold.

5.7. Handling data-rights requests and respecting objections — Article 6(1)(c) GDPR in connection with Articles 12–22 GDPR. A minimal suppression record prevents a person from being added to marketing again; it is not used to continue campaigns.

5.8. These bases concern our own controller operations. They do not replace the Participant's basis for entrusted data, banking-secrecy requirements or document-access restrictions.

6. Cookies and similar technologies

6.1. The Cookie Policy describes the specific names, purposes and lifetimes of cookies and browser storage. A browser identifier's lifetime is not the retention period of its corresponding database record.

6.2. Device storage and access are assessed separately from the GDPR ground for processing personal data. Consent is required before using any technology for which the applicable device-access rule requires it. Functional labels or a legitimate interest do not alone establish an exception. The Cookie Policy distinguishes active technologies, legacy entries and browser lifetimes; those lifetimes do not determine retention by service providers.

7. Recipients and service providers

7.1. We share business details and evidence of actions with the company you represent and authorised participants in the relevant auction or transaction according to their role and access. This does not give every customer access to all other customers' data. Entrusted documents, including debtor information, are subject to the separate rules in section 2.2 and the Terms.

7.2. Authorised BidFinance personnel use personal data for their assigned tasks. Our external service providers include application and database hosting providers, cloud file-storage and recovery providers, business email providers, SMS delivery and telecommunications operators, and technical maintenance and security providers. They receive the information needed for the service: for example, uploaded files and associated metadata for storage or malware scanning, email addresses and message content for email delivery, and telephone numbers and authentication messages for SMS delivery.

7.3. Legal and accounting advisers receive information necessary for their assignment; authorities receive information within a binding legal obligation. Whether a recipient is a processor or a separate controller depends on its actual activities. Processor arrangements must meet Article 28 GDPR. The data processing agreement governs engagement of subprocessors for entrusted data.

7.4. The Platform uses Railway for application hosting and the hosted file-security service, Supabase for its database, and Google Workspace for business email. File storage and SMS delivery are also provided through specialist cloud and communications services. The categories and data involved are described below. Further information about the recipients relevant to your data is available through the privacy contact in section 1.2.

Service / recipient category	Data and purpose
Railway Corporation — application hosting and hosted security services	Data processed through the application, technical and security logs, and uploaded file content needed for malware scanning.
Supabase — database hosting	Account, auction, transaction and other structured Platform records, including database recovery copies.
Google Workspace — business email	Correspondence, recipient and sender details, and delivery information needed to send and receive business and service messages.
Cloud file-storage and recovery providers	Uploaded files, file metadata and recovery copies needed for storage and availability.
SMS delivery providers and telecommunications operators	Telephone numbers, authentication-message content and routing or delivery information.

8. Transfers outside the EEA

8.1. Application hosting is configured in the European Economic Area (EEA). The production database is hosted in Ireland and the staging database in Germany. Service administration, support, security and communications can involve processing outside those hosting regions, including outside the EEA. The provider information below identifies the documented international arrangements; an EEA hosting location does not cover every support or operational access.

Service	Location / international processing	Provider safeguards information
Supabase	Database hosting in the EEA; international support and operational access, including Singapore and the United States.	Supabase's DPA incorporates European Commission standard contractual clauses (SCCs). Its residency information describes SCCs for transfers to Singapore and the United States. Supabase DPA; Data residency and transfers.
Google Workspace	International service and support operations, including the United States.	Google identifies the EU–US Data Privacy Framework for covered US transfers. Its Cloud DPA provides SCC protections for other restricted transfers as specified in its European data-protection provisions. Google Cloud DPA; Google transfer solution.
Railway	Application hosting in the EEA; Railway's DPA describes US operations and international processing.	Railway's published DPA includes SCCs for relevant transfers and provisions on certified adequacy arrangements. Its role-specific clauses and transfer provisions are available at the link below. Railway Terms; Railway DPA.

Cloud file storage and SMS delivery remain recipient categories described in section 7. Their storage, support and routing arrangements are distinct from the application/database regions above. Information about the arrangement relevant to a particular request is available through our privacy contact.

8.2. The linked provider terms explain their data-processing and transfer safeguards. You may request information about the recipients, countries and safeguards relevant to your data, and a copy of the relevant safeguards, using the privacy contact in section 1.2. We may redact confidential third-party information while preserving the information needed to understand the protection provided.

8.3. Our website includes external links to LinkedIn pages and professional profiles. Following a link takes you to LinkedIn, where LinkedIn's Privacy Policy applies to its processing of your data. If you send business correspondence to BidFinance through LinkedIn, our handling of that correspondence is covered by the purposes and rights described in this Policy. LinkedIn Privacy Policy.

9. Retention periods

9.1. The following periods and criteria govern routine retention. We separate current operational data from the limited records needed for legal obligations, transaction evidence or a specific dispute. Retention and deletion are managed through review and controlled operations; these rules do not mean that every record or provider copy is erased automatically when a timer expires.

Category	Period or determining criteria
Account and current profile	For the duration of authorised access. Unnecessary profile data is removed within 30 days after access ends. Any retained identity or transaction evidence must have a separate documented purpose and follows the evidence rules below; closing an Account does not require destruction of necessary transaction records.
Unused invitations	An unactivated profile is reviewed 90 days after the last invitation. We close the invitation and remove unnecessary data if there is no documented continuing need; a decision to continue must identify that need and the next review date. Invitation validity and the retention of necessary correspondence are assessed separately.
Sessions, password resets and authentication challenges	For their validity and, after use, expiry or revocation, only to the extent needed to prevent reuse, resolve an identified security incident or retain justified account-activity evidence. Secret material is assessed separately from limited security metadata. Expiry prevents use but is not itself deletion of the associated record.
Operational diagnostics and limited security/delivery metadata	Ordinary diagnostic records under our operational control: 30 days from the event. Limited security and delivery metadata: 90 days from the event or final delivery state. Necessary business evidence follows the separate rules below. Minimal records preventing duplicate delivery remain only while the underlying event can trigger another delivery. Provider-held technical copies follow the separate copy criteria below.
Ordinary service and business correspondence	Until the matter is completed and necessary follow-up is resolved. Messages needed to establish or defend rights are retained only within the relevant evidence scope and period. Authentication-code and invitation content is handled separately from ordinary correspondence.
Agreements, auction/transaction evidence, signatures and document acceptance	For the limitation period applicable to the relevant claim, measured from its legally relevant starting event. If a specific dispute or proceeding is pending, only the necessary evidence remains until final resolution and the relevant appeal or enforcement period ends. The purpose, record scope and end trigger are recorded; this is not a general right to retain all uploaded data.
Accounting and tax records	For the legally required period applicable to the document. Accounting Act Article 74(2)(1) and (8) generally require at least five years from the beginning of the year following the relevant financial year. Article 74(2)(4) uses the year of final completion, settlement or the other specified event for its document categories. Tax records are kept until the tax liability becomes time-barred under Tax Ordinance Articles 70 and 86, normally five years from the end of the year in which payment was due, subject to statutory exceptions, suspension or interruption.
Detailed marketing contact and campaign history	Reviewed and removed after 12 months without meaningful interaction, except for necessary evidence kept under the separate evidence rules. Meaningful interaction means a reply, request or substantive business discussion; sending another campaign or recording an email open does not restart the period. An objection or withdrawal of channel consent stops the relevant marketing use; minimal suppression and necessary evidence are handled separately.
Minimal suppression records and consent evidence	A minimal suppression record is retained while the same marketing channel or contact-acquisition process presents a real risk of reintroducing the address. It is removed when that risk ends. Consent evidence is kept while relied upon and thereafter only for the applicable period needed to demonstrate the relevant use or address a specific claim or proceeding; detailed campaign history is not retained merely for that purpose.
Entrusted data and VDR documents	For the instructed processing period. Return or deletion follows the Controller's documented choice, the applicable data processing agreement and the Terms, including their agreed deadline. Any continued storage contrary to a deletion instruction requires the applicable legal obligation; a general possibility of future claims does not justify retaining the full entrusted dataset.
Backups, recovery copies and provider-held technical copies	Remaining copies follow the applicable backup, deletion and recovery cycle for the service and the contractual deletion deadline where one applies. They are restricted to the justified recovery, security or legal purpose. Before restored data returns to ordinary use, deletion, restriction and suppression decisions must be reapplied. A log-viewing window or recovery setting does not establish the physical deletion date of every copy.

9.2. Expiry prevents use of a code, link or session; it does not mean its database record has been deleted. Account deactivation likewise does not immediately remove all related documents.

9.3. An extension for a particular legal obligation, incident or dispute must identify the reason, affected data and end condition. It does not extend the retention of unrelated data. When the relevant need ends, the data is removed or irreversibly anonymised through the appropriate controlled process. Requests to exercise data-protection rights are assessed independently under their statutory conditions and deadlines.

9.4. The current managed database plan provides a seven-day daily-backup window. File storage has a 14-day soft-delete recovery setting. These describe specific service features, not a single maximum retention period for all versions, exports or provider copies. Railway's Pro log documentation specifies a 30-day viewing period and allows older logs to become available following a plan upgrade; we do not describe this as guaranteed physical erasure after 30 days.

10. Your rights

10.1. Subject to GDPR conditions, you may request access and a copy, rectification, erasure or restriction. Portability applies to relevant data you have provided that is processed automatically on the basis of consent or a contract with you; it does not automatically cover all Platform records.

10.2. Where processing is based on Article 6(1)(f), you may object on grounds relating to your particular situation. You may object to direct marketing at any time without giving a reason. You may withdraw consent without affecting the lawfulness of earlier processing. Unsubscribing from marketing does not stop necessary Account-service messages.

10.3. Write to info@bidfinance.pl or the address in section 1.1. Describe your request; do not send your password or an unnecessary copy of an identity document. If proportionate identity verification is required, we will explain its scope. Section 2.3 applies to entrusted data.

10.4. You may lodge a complaint with a competent supervisory authority, including the President of Poland's Personal Data Protection Office. Contact details and instructions are available on the UODO website.

11. Automated decision-making

11.1. For administration of customer company User Accounts, BidFinance does not use personal credit scoring or marketing profiling to determine access. Company administrators and authorised BidFinance staff manage User roles and verification; technical authentication and security checks may operate automatically. Auto-Bid follows bidding parameters configured by an authorised company User, and offer selection requires an authorised person’s action. This description concerns company-user Account operations and does not constitute an assessment of automated decisions about individuals whose data may appear in entrusted documents; the role distinction in section 2 applies to those operations.

12. Changes to this Policy

12.1. The publication date is shown with each version. We communicate material changes through an appropriate channel, such as email or a Platform notification. Before beginning processing for a new purpose, we provide the required information about that purpose and the relevant conditions. Updating the text does not itself provide a new legal basis or the user's consent to additional processing.