Privacy Policy

This Privacy Policy ("Policy") explains how Penusila Digital Solutions LLC ("DAF Connect," "we," "us," or "our") collects, uses, discloses, and otherwise processes personal information in connection with the DAF Connect platform — our website at daf-connect.com, the reviewer dashboard, the embeddable intake widget, our APIs, our scheduled automations, and any related tools, demos, and services (collectively, the "Service").

DAF Connect helps enterprise customers (corporate philanthropy programs, donor-advised fund sponsors, family offices, foundations, and other grantmakers) intake, verify, and review non-profit organizations that apply to receive grants, sponsorships, or other support. This Policy is written for three audiences: (a) enterprise customer personnel ("Authorized Users") who sign in to the dashboard, (b) non-profit applicant personnel who submit applications through the embedded intake widget, and (c) visitors to our marketing website.

This Policy is supplemented by our Terms of Service, our Security overview, and — for enterprise customers who require it — a separate Data Processing Addendum. In the event of conflict, the order of precedence is set out in the Terms of Service.

Applicant data submitted through your embed. With respect to the data a non-profit applicant submits through an embedded intake widget into an enterprise customer's workspace, the enterprise customer is the "controller" (in GDPR-style terminology) or "business" (in California law), and DAF Connect acts as a "processor" / "service provider." We process applicant data on the customer's documented instructions and only as needed to (a) provide the Service to that customer, (b) operate the verification features the customer has enabled, (c) maintain security, fraud prevention, and audit logging, and (d) comply with law.

Authorized User account data, marketing-site data, and operational telemetry. With respect to the data we collect about enterprise Authorized Users (their account profile, login records, support correspondence) and visitors to our marketing website (form submissions, analytics, cookies), DAF Connect is the controller.

If you are an applicant and want to exercise rights with respect to data submitted through an enterprise's intake widget (for example, to request access or deletion of your application), please contact that enterprise directly. We will support the enterprise in honoring your request as required by law.

From enterprise customers and their Authorized Users:

• Identity and account data — name, work email address, role/title, password hash (if using email/password), federated identity information from the OAuth/OpenID provider you choose for "Sign in with Apple," "Sign in with Facebook," "Sign in with Google," or "Sign in with Microsoft" (typically your account email, name, profile picture URL, and a stable provider-issued user identifier), workspace memberships, role within a workspace (owner, admin, reviewer, viewer), and invitation tokens. • Workspace configuration data — enterprise name, slug, plan tier, seat count, status, billing contact email, notification destination email, logo URL, brand colors, iframe intro and success copy, allowed embed domains, custom intake question definitions, required-field configuration, public embed key, per-tenant encryption key reference, and feature flags. • Billing data — payment method details and billing records, processed by our payment processor; we do not store full card numbers on our systems. • Operational telemetry — IP address, user agent, browser type, operating system, referrer, session timestamps, page-view events, API request metadata, and audit log entries describing actions taken in the dashboard. • Error and performance monitoring (Sentry) — on every page of the Service, for every visitor, our error-monitoring provider Sentry receives a report when the application crashes or hits an unexpected error, and a sample of performance data. A report can contain: the error message and stack trace; the page address; your browser, browser version, operating system, device type and screen size; the language and timezone your browser reports; the build and environment the error happened in; and "breadcrumbs" — a short trail of what happened in the application just before the error (pages opened, buttons clicked, console messages, and the address, method, status and timing of network requests the page made). Performance tracing records how long page loads, navigations and requests took for about 20% of page views. Sentry also receives the IP address of the connection that sends the report, as any web server does. We do not attach your name, email address or account ID to these reports, Sentry's "send default PII" setting is off, and we do not use Session Replay (screen recording), profiling or user-feedback widgets. These reports are used only to find, diagnose and fix defects and performance problems, and to detect abuse.

From non-profit applicants completing an intake submission:

• Organization identity — legal name, "doing business as" name, EIN (Employer Identification Number), website, website domain, mission statement, NTEE code, founded year, addresses (street, city, state, zip, country), and business address. • Contact data — contact name, email, phone, and any leadership / board / signer information you provide (officers, board members, titles, roles). • Financial data — annual revenue, annual expenses, multi-year financial history, total liabilities, program data, and similar figures. • Banking and signer identity — bank name, account name, routing number, account number, and (where applicable) an image or scan of a government-issued ID for the authorized signer. These sensitive fields are encrypted at rest with a per-tenant AES-256-GCM key and are made readable to reviewers only by an explicit, audit-logged decrypt action. • Custom intake responses — answers to any custom questions the enterprise has configured in its workspace. • Uploaded documents — IRS determination letters, Form 990 filings, financial statements, bylaws, articles of incorporation, board lists, voided checks, signer ID images, and any other documents you choose to upload. Documents are stored under signed URLs, scanned for malware via VirusTotal, and may be reviewed by enterprise personnel. • Submission origin data — the IP address you submit from, the approximate geographic location that IP resolves to (city, region, country, and coordinates), your internet service provider and network operator, whether the connection is detected as a VPN, proxy, or datacenter/hosting range, your browser and operating system, and whether your IP changed during onboarding. This is collected for fraud prevention: it is compared against the address your organization is registered at, and a mismatch or an anonymized connection reduces the trust score and is flagged to the reviewing enterprise. IP geolocation is approximate and is treated as one signal among many, never as a sole basis for a decision. • Optional precise device location — the onboarding form may ask you to confirm your device's precise (GPS) location. This is entirely optional and always behind your browser's own permission prompt: nothing is captured unless you tap "Share my location" and then allow it. When shared, we compare it to your IP location solely to detect spoofing or an anonymized connection, and we store the coordinates, accuracy, and that comparison result on the submission for the reviewing enterprise. If you decline, we record only that you declined — a soft signal the reviewer may see, never a basis for rejection on its own. We do not use precise location for advertising, tracking, or any purpose other than this fraud check. • Verification artifacts — results of EIN format checks, IRS Publication 78 / Tax Exempt Organization Search lookups, OFAC SDN and Consolidated-list sanctions screening, federal debarment / exclusion screening (SAM.gov and the HHS Office of Inspector General List of Excluded Individuals and Entities), federal-award history (USAspending), adverse-media findings, IRS Form 990 financial-forensics signals, ProPublica enrichment, Stripe Connect / Identity / Financial Connections sessions, ownership-match scores, AI verification output (where enabled), dark web / surface web breach and exposure checks on the contact addresses you provide (performed by our screening vendor, Klaw), and trust and risk scores derived from the foregoing. • Fraud-intelligence signals — where enabled, we derive keyed hashes (not reversible clear values) of certain identifiers you or your applicants provide — officer and board names, addresses, bank-account fingerprints, device and IP fingerprints — and compare them, and a keyed hash of grant-fund-advisor identities in the donor-advised-fund grant workflow, to detect shared attributes across applications and, across enterprise tenants, to surface likely fraud rings, disqualified-person relationships, and organizations on a shared negative file of verified-fraud identifiers. Matching is performed on keyed hashes; when a cross-tenant match is confirmed, whether the matched organization's name and the shared attribute value (for example a shared officer name or filing address) are shown in the clear to the other workspace — or anonymized — is controlled by the enterprise workspace that sourced the data, via a name-sharing setting in its own workspace settings (on by default). Bank-account values are only ever shown as their last four digits, and the identity of the other enterprise workspace involved in a match is never disclosed. See Section 12 for details. • Reviewer activity associated with your submission — internal notes, status changes, decisions, email correspondence sent to the contact email you provided, and audit-log entries.

From anyone who interacts with our public forms (human verification and anti-abuse):

• Human-verification challenge — our public forms (application submit, non-profit registration, and the marketing contact form) present a Cloudflare Turnstile "are you human" challenge. Completing it produces a one-time token that we verify with Cloudflare; we do not receive your Cloudflare account identity, and the token is not stored after verification. • Blocked-attempt records — when a request fails or evades the human-verification check, we record the attempt for security and abuse prevention, whether or not the person ever completes an application. The record includes the connection's IP address, the approximate location it resolves to (city, region, country, coordinates), the internet service provider and network operator, whether the IP is a known VPN / proxy / datacenter range, the parsed browser and operating system, the raw user-agent string, and a self-reported device snapshot the browser sends (screen and viewport size, timezone, language, platform, CPU/memory hints, and connection type). This data is used only to detect and deter automated abuse, to lock out repeat offenders for a limited window, and to let the targeted enterprise review blocked traffic. Repeated failures from one connection are temporarily locked out automatically.

From anyone who files a bug or issue report:

• Bug and issue reports — when you use the in-product "Bugs & issues" section, we collect the report's type, title, and description, the page you were on, the severity you select, and your account identity, so our team can investigate, reply, and mark the issue resolved. Do not include sensitive personal data or credentials in a report.

From visitors to our marketing website:

• Contact-form submissions — name, work email, company, company size, role, expected grant volume, message, and source. These are stored as ContactRequest records and used to respond to your inquiry. • Cookies, local storage, and similar technologies — used for session management, draft saving during multi-step onboarding, and security, and — only once you turn the matching category on in the cookie banner or the preferences panel — saved screen preferences and Google Analytics (see Section 8, and the Cookie Policy for every key by name). We do not use cross-site advertising trackers.

Demo environment:

• If you use the demo, we issue a short-lived signed JWT scoped to a synthetic "Acme Community Foundation" demo workspace. The demo seeds sample data and does not require you to register. Demo data is sandboxed and may be deleted periodically.

We use the categories of information described above for the following purposes:

(a) Provide and operate the Service — authenticate Authorized Users, route applicants' submissions to the correct enterprise workspace, render the dashboard, persist drafts, deliver transactional email through our email provider, run the multi-step verification pipeline, compute trust and risk scores, generate audit log entries, run scheduled automations (for example, polling VirusTotal scan results and retention enforcement), and provide customer support.

(b) Security and abuse prevention — detect and prevent fraud, unauthorized access, attacks on the platform, embed-key misuse, and other malicious activity; investigate incidents; back up and restore data; and enforce our Terms of Service and acceptable-use rules.

(c) Verification — submit relevant data fields (such as EIN, organization name, address, signer identity information) to verification providers (Stripe, the IRS, OFAC, ProPublica, CharityAPI.org, VirusTotal, GIACT where the enterprise has enabled it, and AI/LLM providers where the enterprise has enabled AI verification) so that we can return verification results to the reviewer.

(d) Communicate with you — respond to inquiries submitted via our contact form, notify enterprise customers of decisions or status changes, send applicants decision and more-info-requested emails on behalf of the enterprise, send service announcements, and (where permitted and with appropriate opt-out) send product updates to enterprise contacts. We do not send marketing email to applicants.

(e) Billing — process subscription fees and maintain financial records.

(f) Improve the Service — analyze aggregated, de-identified usage data to monitor performance, debug, and improve features. We do not use applicant submission content to train or fine-tune our own or third-party machine-learning models, and we instruct our LLM providers not to do so on our behalf to the extent their terms permit. AI verification, where enabled, processes applicant data for the immediate inference only.

(g) Comply with legal obligations — respond to lawful requests, defend legal claims, enforce our agreements, and maintain records required by law.

Where the GDPR or UK GDPR applies to processing of your personal data and DAF Connect is acting as a controller, we rely on the following legal bases:

• Performance of a contract — to provide the Service to enterprise customers and their Authorized Users. • Legitimate interests — to operate, secure, and improve the Service, prevent fraud and abuse, respond to inquiries from our website, and conduct limited B2B marketing to enterprise contacts. Where we rely on legitimate interests, we balance those interests against your privacy rights and you may object as described in Section 9. • Consent — where required, for example for the analytics and functional cookie categories (each withdrawable on its own under Cookie settings) or for marketing communications to website inquirers. You may withdraw consent at any time. • Legal obligation — to comply with applicable law, court orders, and government requests.

Where DAF Connect acts as a processor on behalf of an enterprise customer (for example, with respect to applicant submission data), the legal basis is determined by the enterprise customer.

We do not sell personal information, and we do not share personal information for cross-context behavioral advertising. We share information only as described below.

(a) Within an enterprise's workspace — applicant submission data, verification artifacts, internal notes, decisions, and email correspondence are visible to the Authorized Users of the enterprise that received the application, subject to that enterprise's role-based access controls (owner, admin, reviewer, viewer).

(b) Sub-processors — we use the following sub-processors to operate the Service. Each is bound by contractual confidentiality and data-protection obligations and is permitted to process data only on our documented instructions for the purposes stated:

• Base44 — the application platform this Service runs on: hosting, database, file storage, function execution, authentication, and the storage behind our audit log. Receives all categories of data. Region: United States. Base44 runs on cloud infrastructure of its own choosing; that provider is Base44's sub-processor, not ours, and we do not hold a direct relationship with it. • Stripe, Inc. — organization / tax-ID verification (Stripe Connect), bank ownership verification (Stripe Financial Connections), and signer identity verification (Stripe Identity). Receives PII and financial data of the applicant's signer and organization. Region: United States. • Internal Revenue Service public APIs — Publication 78 / Business Master File / Tax Exempt Organization Search lookups. Receives EIN and organization name. Region: United States. • U.S. Treasury OFAC public list — sanctions screening. We screen organization name (and may screen address) against the SDN list and consolidated lists. Region: United States. • U.S. General Services Administration (SAM.gov) and the HHS Office of Inspector General (LEIE) — federal debarment / exclusion screening of the organization and its named principals. Receive organization and principal names and, where available, EIN. Region: United States. • USAspending.gov — federal-award history used to corroborate established grantees. Receives organization name / EIN. Region: United States. • Cloudflare, Inc. — human-verification challenge (Turnstile) on public forms and network-layer security. Receives the challenge token and the connection's IP address. Region: global edge network. • ip-api.com (IP geolocation) — resolves the approximate location, network operator, and VPN / proxy / hosting classification of an IP address for the submission-origin and blocked-attempt signals. Receives the IP address only. Region: United States / EU. • Klaw — dark-web, surface-web, breach-exposure, and PEP screening of the contact identities you provide. Receives contact names and email addresses. Region: United States. • ProPublica Nonprofit Explorer — supplemental enrichment for non-profits. Receives EIN and organization name. Region: United States. • CharityAPI.org — IRS registry corroboration (Publication 78 listing and deductibility) and nonprofit name search. Receives EIN and organization name. Region: United States. • GIACT (part of LSEG Risk Intelligence) — an alternative verification rail, used only where it is enabled for an enterprise's workspace: bank-account ownership, business identity with an IRS TIN match, signer identity, and sanctions screening. Receives bank routing and account numbers, organization name, EIN and address, and the signer's name, date of birth and contact details. Until production credentials are issued, requests go to GIACT's sandbox environment and the results are labelled as such and never treated as authoritative — but the data sent is still real applicant data. Region: United States. • VirusTotal (Google LLC) — malware scanning of uploaded documents. Receives document hashes and may receive document content. Region: United States / Google-operated infrastructure. • Resend, Inc. — transactional email delivery (decision emails, more-info-requested emails, contact-form confirmations). Receives recipient email address, name, and email body. Region: United States. • Functional Software, Inc. (Sentry) — application error, crash and performance monitoring on every page of the Service. Receives the error and performance reports described in Section 3 (error messages, stack traces, page addresses, browser / operating system / device details, breadcrumbs of recent in-app activity and network requests, timing data) and the IP address of the connection sending them. No account name, email, or ID is attached. Region: United States. • Federated sign-in providers — "Sign in with Apple" (Apple Inc.), "Sign in with Facebook" (Meta Platforms, Inc.), "Sign in with Google" (Google LLC), and "Sign in with Microsoft" (Microsoft Corporation / Microsoft Entra ID) for Authorized Users who choose one of those sign-in methods. Each receives an authentication request and returns a provider-issued user identifier, account email, display name, and (where available) profile picture URL. See Section 7 for additional provider-specific disclosures. • AI / LLM providers — where AI verification is enabled for an enterprise's workspace, relevant submission text and document text may be sent to an LLM provider to generate verification summaries and risk flags. Inputs and outputs are processed under the provider's enterprise / no-training terms. Region: United States.

We may add or change sub-processors. Material changes will be communicated to enterprise account owners by email or in-product notice at least fourteen (14) days before they take effect, except where a shorter period is required for security, legal, or compliance reasons. A current list is mirrored in the Security overview. Certain additional verification vendors (for example, Secretary-of-State registry data, additional TIN / entity matching, document-forgery forensics, and address-type verification) are described on our public site as forthcoming; they are not active and receive no data until we enable them and update this list.

(b-bis) Cross-tenant fraud intelligence. To detect fraud rings that span "unrelated" applicants and multiple enterprise workspaces, we compute keyed hashes of certain identifiers (officer/board names, addresses, bank-account fingerprints, device and IP fingerprints, and — in the donor-advised-fund grant workflow — fund-advisor identities) and match those hashes across tenants. Matching itself runs on hashed values — we do not pool raw identifiers to compare them. What a confirmed cross-tenant match reveals is controlled by the workspace that sourced the data: each enterprise workspace chooses, in its own settings, whether its applicants' organization names and shared attribute values (for example a shared officer name or filing address) are shown in the clear to other workspaces' reviewers, or anonymized (masked). Name sharing is on by default — a match that cannot be read is far harder to judge, and readable ring evidence is a core fraud-prevention function of the Service — but a workspace may switch to anonymized at any time, and the change applies to how its data appears in matches from then on. Two things are never disclosed in a cross-tenant match: full bank-account numbers (bank values are stored and displayed as last-four only) and the identity of the other enterprise workspace involved. A shared negative file of verified-fraud identifiers is built but not yet in use — it is not populated and no submission is checked against it; once switched on it will operate the same way, with a documented dispute process; advisor-to-officer matching in the grant workflow returns only a yes/no signal and never reveals which individual matched. EINs are treated as public identifiers and may appear in the clear.

(c) Affiliates — we may share information with our corporate affiliates for the same purposes set out in this Policy, subject to the same protections.

(d) Successors — if we are involved in a merger, acquisition, financing, reorganization, bankruptcy, or sale of all or part of our assets, information may be transferred to the successor or acquirer, subject to this Policy or a successor policy that is no less protective.

(e) Legal and safety — we may disclose information when we have a good-faith belief that disclosure is necessary to (i) comply with applicable law, regulation, legal process, or governmental request, (ii) enforce our Terms of Service or other agreements, (iii) detect, prevent, or otherwise address fraud, security, or technical issues, or (iv) protect the rights, property, or safety of DAF Connect, our customers, our users, or others.

(f) With your direction — where you direct us to share information with a third party (for example, by exporting an audit log or downloading submission data).

DAF Connect offers four federated sign-in options for enterprise Authorized Users: "Sign in with Apple," "Sign in with Facebook," "Sign in with Google," and "Sign in with Microsoft." Each uses the provider's standard OAuth 2.0 / OpenID Connect flow.

Data we receive from each provider. In every case, we receive only what is necessary to identify and authenticate you. We do not access your contacts, calendar, photos, files, social-graph friends, posts, drive contents, mail, or any other content stored with the provider.

• Sign in with Apple (Apple Inc.) — we request the "name" and "email" scopes. Apple returns a stable Apple user identifier, your name (only on first sign-in, if you choose to share it), and either your real Apple ID email or a private relay email address that you can choose to use. We treat the relay address as your account email; replies to it are routed by Apple to your real address. • Facebook Login (Meta Platforms, Inc.) — we request the "email" and "public_profile" scopes. Facebook returns a Facebook user ID, your name, your account email (where available), and your profile picture URL. We do not request any Facebook permission that requires App Review beyond standard sign-in. • Sign in with Google (Google LLC) — we request the "openid", "email", and "profile" scopes. Google returns a stable Google account identifier, your email address, your name, and your profile picture URL. • Sign in with Microsoft (Microsoft Corporation) — we use the Microsoft identity platform (Azure AD / Microsoft Entra ID) and request the "openid", "email", "profile", and "User.Read" scopes. Microsoft returns a stable object identifier, your work or personal account email (UPN), your display name, and (where available) your profile picture.

How we access this data. We access data only through each provider's standard, user-facing consent screen. You must explicitly approve the requested scopes before any data is shared with us.

How we use this data. Provider sign-in data is used solely to (1) create and authenticate your DAF Connect account, (2) display your name, email, and profile picture in the application interface, (3) attribute your actions in audit logs, and (4) support customer-support correspondence with you. We do not use this data for advertising, profiling, retargeting, behavioral analysis, or to train or fine-tune AI or machine-learning models.

How we store this data. Your provider email, display name, profile picture URL, and provider-issued user identifier are stored in our user database alongside your DAF Connect account record. We do not store your provider password. OAuth refresh tokens, where issued, are stored only for as long as required to maintain your session and are encrypted at rest.

How we share this data. We do not sell, rent, transfer, or share federated sign-in data with any third party for that third party's own purposes. It is never shared with non-profit applicants, with other enterprise tenants, or with advertising networks. The only sub-processors with access are the application platform that hosts our database (Base44), processing the data solely on our behalf under contractual confidentiality obligations, and the email-delivery provider (Resend) when we send you transactional emails.

Revoking access. You may revoke DAF Connect's access to your provider account at any time through that provider's account-management pages:

• Apple — https://appleid.apple.com/account/manage (Sign in with Apple → Apps & Websites). • Facebook — https://www.facebook.com/settings?tab=applications (Apps and Websites). • Google — https://myaccount.google.com/permissions. • Microsoft — https://account.live.com/consent/Manage (personal) or your tenant admin's Enterprise Applications panel (work/school).

Revoking access disables that sign-in method for your DAF Connect account; you may still sign in via other configured methods or contact information@daf-connect.com to delete your DAF Connect account entirely, in which case we will delete or de-identify the provider data we hold about you, subject to the retention obligations described in Section 10.

Provider-specific commitments.

• Google. DAF Connect's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not transfer Google user data to third parties except as necessary to provide or improve the Service and only with your consent, for security purposes, or to comply with applicable law. • Apple. We use Apple sign-in solely for authentication. We do not contact you at the Apple private relay address for marketing purposes and we do not attempt to correlate the relay address with your real Apple ID. • Facebook. We use Facebook Login solely for authentication. We do not request, store, or use any Facebook permission that would let us read your timeline, friends list, posts, messages, or other social content. We comply with Meta's Platform Terms and Developer Policies. • Microsoft. We use the Microsoft identity platform solely for authentication and to retrieve basic profile data. If your workplace has registered DAF Connect as an enterprise application in your Microsoft Entra ID tenant, your tenant administrator controls access and may revoke our app's permissions at any time. We do not request Mail.Read, Files.Read, Calendars.Read, or any other content-access scope.

Each provider has its own privacy policy and terms governing their relationship with you. Your use of a provider's sign-in service is also subject to those documents.

This section is the summary. The Cookie Policy lists every cookie and storage key by name, with who sets it, why, and for how long, and explains how the consent banner works and what U.S. state, federal and international law gives you the right to ask for.

We use a small, fixed set of cookies and browser storage, in four categories — two you decide and two the site cannot work without. Analytics and Functional are off until you turn them on in the cookie banner or the preferences panel, and this section lists exactly what the site loads.

Strictly necessary (always on):

• Session cookies — keep you signed in while you use the reviewer dashboard or the nonprofit portal. • Security cookies and tokens — mitigate cross-site request forgery, bind multi-factor sessions to a device, and enforce the temporary lock-out after failed human-verification checks on public forms. • Local storage for what you have typed — persists draft submissions during multi-step onboarding so you can resume without losing progress (keyed to the enterprise's public embed key, or to the demo key). This is your own input into a form you opened, kept for that task and deleted when it is submitted, so it is not behind a switch. Sensitive fields — EIN, bank details, signer ID files and the human-check token — are removed before the draft is saved at all. • Your cookie choice itself — stored under the key "daf-connect-cookie-consent" as {version, categories, at}, with one true/false per category, so we do not ask you again. • Demo session token — for the demo environment, a token in sessionStorage that opens the sample workspace, expires after about an hour, and is not tied to an account. • Error and performance monitoring (Sentry) — the Sentry script runs on every page so that crashes and errors reach us and can be fixed (see Section 3). It sends reports to Sentry's servers and keeps its working state in memory for the page you have open; it does not set an advertising or cross-site tracking cookie. It has no switch because finding and fixing defects and abuse in the Service is part of operating it securely. • First-party page logs — our hosting platform records which section of the application was opened (for example "app" or "docs") through a same-origin request to our own servers. It sets no cookie and no third party receives it.

Payments and security (always on, and only on the screens that need them):

• Cloudflare Turnstile — the human-verification challenge on our public forms sets a challenge token for the duration of the check (see Section 3). • Stripe — when you link a bank account, Stripe sets its own fraud-prevention identifiers (__stripe_mid, __stripe_sid) on that screen. They are not set by the page you are reading, and they are not set at all unless you open a payment or bank-verification step. This group has no switch: fraud prevention for a payment you asked us to make is not optional, and a switch we would ignore would be worse than saying so.

Functional (only with your consent, and off until you give it):

• How you like our screens arranged once the job is done — list or board, which queue tab is open, whether drafts are shown, a collapsed demo sidebar, a reviewer introduction you closed. These are written only while the Functional category is on, and turning it off deletes them from your browser at that moment. Nothing here leaves your browser.

Analytics (only with your consent, and off until you give it):

• Google Analytics 4 (Google LLC), property G-49QDQYNH24. Nothing from Google Analytics is loaded until you turn Analytics on — with "Accept all" in the cookie banner, or with the Analytics switch under "Customise"; if you choose "Reject non-essential", leave it off, or never choose, no request is made to Google Analytics at all. (Our webfonts are served from our own site, not from Google.) When you accept, the gtag.js library loads with Google Consent Mode set to deny advertising storage, ad user data and ad personalization — only analytics storage is granted. It sets the _ga and _ga_* cookies (up to two years) and records the pages you view, the referring site, your device and browser type, and an approximate location derived from your IP address, which Google truncates before storage. We send one page view per page you open, and the address we report is redacted first: one-time tokens, invitation codes, sign-in handles and return URLs in the query string are replaced with the word "redacted" before anything leaves your browser. We do not use Google Signals, advertising features, or cross-site remarketing. Google describes its own processing at https://policies.google.com/technologies/partner-sites.

Global Privacy Control. If your browser sends the Global Privacy Control signal, we treat it as a refusal of everything optional: the banner does not appear, Google Analytics does not load, and no functional key is written, unless you later turn a category on explicitly under Cookie settings.

Changing your choice. Select "Cookie settings" in the footer of any page to open the preferences panel with your saved choices already filled in, move any switch, and press "Save my choices". The change applies immediately, with no reload: turning Analytics off stops further measurement in this browser, sets no new analytics cookies and expires the _ga cookies already set; turning Functional off deletes that category's keys from your browser in the same moment. Clearing site data in your browser removes both the stored choice and any analytics cookies. Blocking strictly necessary cookies may impair access to the Service. The Cookie Policy lists every key by name and explains each category and each switch.

We do not use third-party advertising cookies, cross-site tracking pixels, or behavioral profiling.

Depending on your location, you may have the following rights with respect to personal information we hold about you as a controller:

• Right of access — to obtain confirmation of whether we process personal data about you and a copy of that data. • Right to rectification — to correct inaccurate or incomplete personal data. • Right to erasure ("right to be forgotten") — to request deletion of personal data, subject to legal exceptions. • Right to restrict processing — to limit how we use your personal data in certain circumstances. • Right to data portability — to receive your personal data in a structured, commonly used, machine-readable format and, where technically feasible, to have it transmitted to another controller. • Right to object — to object to processing based on legitimate interests, including direct marketing. • Right to withdraw consent — where processing is based on consent, to withdraw at any time without affecting the lawfulness of prior processing. • Right to non-discrimination — under California law, to not receive discriminatory treatment for exercising your rights. • Right to opt out of "sale" or "sharing" — under California law, where applicable. DAF Connect does not sell personal information and does not share personal information for cross-context behavioral advertising.

How to exercise your rights. Enterprise Authorized Users may contact us at information@daf-connect.com. Non-profit applicants should contact the enterprise to which they submitted their application; we will assist that enterprise in honoring valid requests. We will respond within the timeframes required by applicable law (generally thirty (30) to forty-five (45) days). We may need to verify your identity before responding and may decline requests where permitted by law (for example, where granting the request would adversely affect another person's rights or where we are required to retain the data).

EU/UK complaints. You may also lodge a complaint with your local supervisory authority — for example, the UK Information Commissioner's Office (ICO) or your EU data protection authority.

Authorized agents. California residents may use an authorized agent to submit requests; we may require written authorization and identity verification.

We retain personal data for as long as needed to provide the Service and for the additional periods described below.

• Enterprise account and Authorized User data — retained for the duration of your enterprise account plus a reasonable wind-down period (typically thirty (30) days after termination), after which we delete or de-identify, except as required for legal, accounting, or audit purposes. • Submission data and verification artifacts — retained for the duration of the enterprise account's active status plus three (3) years, unless the enterprise has configured a shorter retention or has requested deletion. Our scheduled retention enforcement automation archives stale submissions (soft delete) and then hard-deletes after a grace period, subject to legal hold. • Audit log entries — retained for five (5) years, in append-only form, to support compliance and investigations. • Blocked-attempt records and hashed fraud-intelligence signals — retained for as long as needed for security and abuse prevention and to maintain the integrity of the fraud-detection graph, then deleted or de-identified. Automatic lock-outs expire within a short window (on the order of minutes). • Bug and issue reports — retained for the life of the account or until resolved and no longer needed for product-quality records. • Email logs (decision and more-info emails) — retained for the duration of the related submission's retention period. • Demo data — retained for short periods only and may be deleted on a recurring cleanup schedule. • Backups — encrypted backups are retained for up to thirty-five (35) days and then overwritten on rolling cycles. • Financial records — retained as required by tax and accounting law (typically seven (7) years).

When data reaches the end of its retention period, we delete or irreversibly de-identify it, except where ongoing legal obligations, dispute defense, or technical infeasibility require otherwise. Where deletion is impracticable in the short term (for example, data residing in backups), we securely isolate it and delete on the next available cycle.

The Service is hosted in the United States. If you access the Service from outside the United States, you understand that your personal data will be transferred to and processed in the United States, which may have data-protection laws different from your jurisdiction.

Where we transfer personal data of individuals in the European Economic Area, the United Kingdom, or Switzerland to the United States or other third countries, we rely on appropriate safeguards as required by applicable law, including the European Commission's Standard Contractual Clauses (and the UK International Data Transfer Addendum where applicable). Enterprise customers requiring an executed Data Processing Addendum incorporating these clauses can request one at information@daf-connect.com.

We implement administrative, technical, and physical safeguards designed to protect personal data against unauthorized access, loss, alteration, and disclosure. These measures include:

• Encryption — TLS 1.2+ in transit; AES-256 at rest, which is the hosting platform's control rather than ours and rests on its attestation; per-tenant AES-256-GCM application-layer encryption, which is ours, for designated sensitive fields (EIN, banking details, signer ID image references). Decryption requires an explicit, second-factor-gated, audit-logged action by an authorized reviewer. • Access controls — role-based access (owner / admin / reviewer / viewer), tenant-scoped row-level security enforced at the API layer (not just in the UI), domain allowlisting for embed widgets, scoped public embed keys, and a separate signed-JWT system for the demo. • Audit logging — append-only logs of actor user, IP, user agent, action, before/after state, and timestamp. • Document handling — uploaded files served only via short-lived signed URLs; malware scanning via VirusTotal on upload, with a scheduled job to resolve pending scans. • Abuse prevention — a human-verification challenge (Cloudflare Turnstile) on public forms that fails closed, with automatic temporary lock-out of connections that repeatedly fail or evade it, and a per-tenant-visible ledger of blocked attempts. • Cross-tenant matching over keyed hashes — fraud-ring and advisor-to-officer signals (and negative-file matches, once that file is in use) are computed over keyed hashes, never by pooling raw identifiers. Whether a confirmed ring match surfaces the matched organization's name in the clear or anonymized is each sourcing workspace's own setting (see Section 4(b-bis)); bank accounts stay last-four only, and no enterprise workspace's identity is revealed to another. • Operational practices — least-privilege access, a service-role-only secret store, continuous dependency and code scanning (Aikido, whose external audit report is linked from every page), change control, and hosting on the Base44 platform in the United States. We have not commissioned an independent penetration test or a SOC 2 or ISO 27001 audit; the Security overview says what has and has not been tested.

No security control is impenetrable. If you become aware of a security incident or suspected vulnerability, contact information@daf-connect.com promptly. Our vulnerability disclosure expectations are described in the Security overview.

The Service is intended for use by adults acting in a professional capacity. It is not directed to children under the age of sixteen (16), and we do not knowingly collect personal information from children. If you believe a child has provided us with personal information, contact information@daf-connect.com and we will take appropriate steps to delete it.

Some features of the Service generate automated outputs — for example, EIN format checks, IRS status lookups, OFAC screening results, drift detection, trust and risk scores, and (where enabled by the enterprise) AI-assisted verification recommendations.

These outputs are tools to help human reviewers. They do not constitute a final decision on any application. The enterprise reviewer remains responsible for the final decision. Where required by applicable law, the enterprise must inform applicants of any meaningful automated processing and honor applicable rights, including the right to obtain human intervention, to express a point of view, and to contest a decision based solely on automated processing. DAF Connect will support the enterprise in honoring such rights.

Where AI verification is enabled, submission content may be processed by an LLM provider for the purpose of generating that single verification output. Inputs and outputs are not used by the provider to train its general-purpose models, to the extent that provider's enterprise / API terms guarantee.

Transactional and service emails. We send service-related emails to enterprise Authorized Users (account, billing, security, decision notifications, status changes, password reset) and on the enterprise's behalf to applicants (decision and more-info emails). You cannot opt out of essential service emails while you have an active account.

Product updates and announcements. We may send infrequent product updates to enterprise account contacts. You may opt out of non-essential communications by following the unsubscribe link in those messages or by contacting information@daf-connect.com.

Marketing inquiries. If you submit our marketing-website contact form, we will use the information you provided to respond and may follow up about your interest. We do not send marketing email to non-profit applicants.

SMS / phone. We do not send SMS marketing. We may contact you by phone only if you have specifically requested it.

We may update this Policy from time to time. Material changes will be communicated to enterprise account owners by email or in-product notice at least fourteen (14) days before they take effect, except where a shorter period is required for legal, security, or compliance reasons. The effective date at the top of this page reflects the most recent update.

Your continued use of the Service after the effective date of an updated Policy constitutes your acceptance of the updated Policy. If you do not agree, you may stop using the Service and request deletion of your account.

California (CCPA / CPRA). In the twelve (12) months preceding the effective date of this Policy, we have collected the categories of personal information described in Section 3 (including identifiers, professional information, commercial information, internet/network activity, and limited financial information for billing), from the sources described in Section 3 (you, applicants, your enterprise, our service providers, and public data sources), for the purposes described in Section 4. We have disclosed personal information to the sub-processors described in Section 6 to provide the Service. We do not "sell" personal information and do not "share" personal information for cross-context behavioral advertising as those terms are defined under California law. We do not use or disclose "sensitive personal information" for purposes that would require a right to limit under the CPRA, other than as permitted by Section 7027(m) of the CPRA regulations. California residents may exercise the rights described in Section 9.

Other U.S. state privacy laws (e.g., Virginia, Colorado, Connecticut, Utah, Texas, Oregon). Residents of states with comprehensive privacy laws have the rights described in Section 9 to the extent provided by their state's law. You may submit requests to information@daf-connect.com. We do not engage in "targeted advertising," "sale" of personal data, or "profiling in furtherance of decisions that produce legal or similarly significant effects" of consumers, as those terms are defined under those laws.

If you are an enterprise customer Authorized User, you may exercise these rights directly. If you are a non-profit applicant, please contact the enterprise to which you applied.

General privacy inquiries, data subject requests, and security incidents all reach us at information@daf-connect.com. Our mailing address is available on request at the same address.

For complaints regarding our handling of personal data, please contact us first so we can attempt to resolve the issue. If you are in the EU, UK, or Switzerland, you also have the right to lodge a complaint with your local supervisory authority.