Every third party that touches blankit data.

Blankit Health Inc. operates inside AWS, primarily in AWS Canada (Montreal, ca-central-1). The list below is the complete inventory of third parties that may process personal information in connection with the platform, the purpose of that processing, and how it addresses Quebec Law 25 and PIPEDA cross-border obligations. Where a vendor operates outside Canada, that is stated explicitly.

The list covers two kinds of third party, and the difference matters for who holds the contract. Some are engaged by blankit and process personal information on our behalf — hosting, email delivery, billing, AI inference. They are in the production data path for every firm, and we notify firms at least 30 days before adding one. The rest are integrations a firm connects itself to systems it already uses — its CRM, its document folder, its Slack or Microsoft Teams workspace, its mailbox. Those are off by default, connected only by an administrator of the firm, and governed by the firm’s own agreement with that vendor rather than by ours; disconnecting stops the processing. They are listed here anyway, because what matters to a plan sponsor asking where their data can travel is the complete picture, not the contractual boundary.

Amazon Web Services Canada (storage + compute)

Location: Canada (ca-central-1, Montreal)

Purpose: Hosting, database (RDS PostgreSQL), object storage (S3), and secrets management (KMS)

Data: All client data at rest. Application servers, database, object storage, and backups.

ActiveDetails

Transfer mechanism: Application servers, database, object storage, and backups are all hosted in Canada. AWS Canadian Customer Agreement governs. AI processing is a separate AWS service, listed below with its own location.

Stripe Payments Canada

Location: Canada with US data processing

Purpose: Subscription and usage-based billing for firms that subscribe to blankit

Data: Firm billing contact identity and the firm’s aggregate AI-usage quantities (credit counts for metered billing) — no plan-sponsor or plan-member data, and no per-advisor detail

ActiveDetails

Transfer mechanism: Stripe DPA + PCI DSS Level 1 controls. Plan-sponsor and plan-member data is never sent to Stripe.

Amazon Web Services Canada (Amazon SES — outbound email)

Location: Canada (ca-central-1, Montreal)

Purpose: Outbound transactional email — sign-in and password emails, firm notifications and digests, and the name and contact details a plan member submits when they ask an advisor to follow up or enrol in optional coverage

Data: Recipient email address and the body of the email, which can include a plan member’s name, email address, phone number and the question they asked an advisor

ActiveDetails

Transfer mechanism: Sent from Canada under the AWS Canadian Customer Agreement. Once delivered, a message is held by the recipient’s own email provider, wherever that provider stores mail. Health information is never sent by email: a signed health questionnaire or an application carrying tobacco status is opened through an expiring secure link to blankit, where it stays stored in Canada.

Slack Technologies (Salesforce)

Location: United States

Purpose: Two separate, independently installed integrations. (1) Advisor workspace — when a firm connects its own Slack, documents shared in the channels it maps are read into blankit, and analysis outcomes, alerts and generated documents are posted back. (2) Plan sponsor workspace — where an employer installs Paige, the employee chatbot, their employees can ask coverage questions in Slack and get answers drawn from their own plan booklet.

Data: Advisor workspace: whatever the firm chooses to share — carrier renewal and claims documents, client names, premium and claims figures, and generated reports. Plan sponsor workspace: the employee’s question, the answer, and their Slack user id. No name or email is requested there. The question is held only for as long as it takes to answer it — Slack requires a fast acknowledgement, so it is queued while a background worker produces the reply, and that queue row is cleared as soon as the reply is delivered. One further holding is disclosed because a plan sponsor asking where their employees’ words go is entitled to the complete answer: the last few messages of a conversation are held for about thirty minutes, in temporary storage outside any firm’s database, so the chatbot can answer a follow-up; they expire automatically, and an employee can clear them at once by typing “start over”. Employees are told this in the notice shown before their first question. Nothing is sent to Slack for a firm, or an employer, that has not connected it.

ActiveDetails

Transfer mechanism: Slack Customer Agreement + DPA, held between the workspace owner and Slack — the firm for its own workspace, the employer for theirs. Both integrations are off by default and connected only by an administrator of the workspace concerned; disconnecting stops all further processing. Documents and questions are stored in Canada; the AI step that reads them runs through whichever AI sub-processor is marked active below, on that entry’s stated terms. Slack itself is the transport and the destination for the reply, not the processing location. For the plan-sponsor integration one consequence is worth stating plainly rather than leaving implied: the workspace belongs to the employee’s employer, so what that employer can see or export from it — including direct messages with apps, on some Slack plans — is governed by Slack’s administrator controls and the employer’s own Slack agreement, not by blankit. Employees are told this before their first answer, and are offered the web chatbot, which their employer cannot see, as the private alternative.

Meta Platforms (WhatsApp Business Platform)

Location: United States and Ireland

Purpose: Transport for the plan-member benefits chatbot on WhatsApp — the employee’s question reaches blankit through Meta, and the answer goes back the same way. blankit never starts a conversation: every message it sends is a reply to one an employee sent first, and no message templates are registered, so there is no mechanism by which an employee can be messaged unprompted.

Data: The employee’s question, the answer, and their mobile number — which on this surface is how the message is addressed and cannot be withheld from the transport. blankit itself stores a scrambled code derived from that number, never the number, so blankit’s own records cannot be used to contact anyone; the number is written down once, in the queue row that carries the reply, and that row is cleared as soon as the answer is delivered. One further holding is disclosed here for the same reason it is on the Slack row above: the last few messages of a conversation are held for about thirty minutes, in temporary storage outside any firm’s database, so the chatbot can answer a follow-up; they expire automatically, and an employee can clear them at once by typing “start over”. Employees are told this in the notice shown before their first answer. No name, no email, and no profile field is requested. Photos, documents and other media sent to the number are ignored rather than read.

ActiveDetails

Transfer mechanism: WhatsApp Business Solution Terms + Meta’s data processing terms, held between blankit and Meta — unlike the Slack row above and the Microsoft Teams row below, this agreement is not the employer’s. ⚠️ What this surface adds is the MESSAGE crossing the border, in transit. The plan booklet the answer is drawn from and the client’s data stay stored in Canada, and the AI step that reads them is the same as on every other version of the chatbot — through whichever AI sub-processor is marked active below, on that entry’s stated terms — so nothing about where a plan sponsor’s data is stored changes because their employees use this surface. One consequence worth stating plainly, because it runs the opposite way to Slack and Teams: the WhatsApp account belongs to the EMPLOYEE, not to their employer, so an employer has no administrative visibility into these conversations at all. Employees are told all of this before their first answer, and can end it at any time by replying STOP.

Microsoft (Teams, through the Azure Bot Framework)

Location: United States (Microsoft’s Bot Framework relay); the firm’s own Microsoft 365 tenant otherwise holds the conversation, wherever that tenant is hosted

Purpose: Advisor organization — when a firm adds blankit to its own Microsoft Teams, documents shared in the channels it sets up are read into blankit, analysis outcomes are posted back to the channel, and firm members can ask blankit about their own book from Teams. Only firm members matched by their Microsoft 365 email can feed documents through it; a guest or a client in a shared channel cannot.

Data: Whatever the firm chooses to share — carrier renewal and claims documents, client names, premium and claims figures — and the replies posted back. A channel upload lands in the firm’s own SharePoint and is fetched from there; blankit reads messages only in channels the app is added to and that the firm has set up for a document type. Nothing is sent to Microsoft for a firm that has not connected it.

ActiveDetails

Transfer mechanism: Microsoft Product Terms + DPA, held between the firm and Microsoft. The integration is off by default and connected only by a firm administrator, using a single-use connection code issued in blankit; disconnecting stops all further processing. Documents are stored in Canada; the AI step that reads them runs through whichever AI sub-processor is marked active below, on that entry’s stated terms. Microsoft’s Bot Framework is the transport and the destination for the reply, not the processing location.

Customer relationship management — Salesforce, HubSpot, Zoho, Microsoft Dynamics

Location: United States (Zoho and Dynamics offer other regions; the firm’s own tenant decides)

Purpose: Only where a firm connects its own CRM. blankit reads client records to match them to the firm’s book, and — only if the firm switches the connection to bidirectional — writes mapped fields such as renewal dates and premium figures back onto the matching record. The default is pull-only: nothing is written back unless an administrator turns that on.

Data: Plan sponsor (employer) names and contact details, renewal dates, and the premium and renewal figures the firm chooses to map. No plan-member data, no claims detail, and no booklet content is written to a CRM.

ActiveDetails

Transfer mechanism: The firm’s own agreement with its CRM vendor — blankit is not a party to it, and the data is going into a system the firm already controls and already holds this information in. Off by default, connected only by a firm administrator, and disconnecting stops all further processing. Listed here for transparency rather than because blankit engages these vendors: like the Slack advisor workspace above, the contract is the firm’s.

Intuit (QuickBooks Online)

Location: Wherever Intuit hosts the firm’s QuickBooks Online company, under Intuit’s own terms; blankit does not choose it

Purpose: Only where a firm connects its own QuickBooks Online company. When someone at the firm presses Send on the Commissions page, blankit creates one invoice per carrier statement and, where the firm shares commission with outside co-brokers, one bill per co-broker per month. To avoid duplicates and use the right records, blankit first looks up the customers, vendors, service, account and tax code it needs, and which of its own invoice and bill numbers the company already holds.

Data: Carrier names, the firm’s client (plan sponsor) names and policy numbers, commission amounts and statement dates; for co-broker bills, the outside co-broker’s name and the share owed. No plan-member data, no claims detail and no booklet content is sent to QuickBooks.

ActiveDetails

Transfer mechanism: The firm’s own agreement with Intuit — blankit is not a party to it, and the data goes into the firm’s own books. Off by default, connected only by a firm administrator; the access credentials are encrypted at rest, and disconnecting stops all further processing. Listed for transparency rather than because blankit engages Intuit: like the CRM entry above, the contract is the firm’s.

Xero

Location: Wherever Xero hosts the firm’s Xero organisation, under Xero’s own terms; blankit does not choose it

Purpose: Only where a firm connects its own Xero organisation. When someone at the firm presses Send on the Commissions page, blankit creates one draft invoice per carrier statement and, where the firm shares commission with outside co-brokers, one draft bill per co-broker per month, booked to the account codes the firm chose. To avoid duplicates, blankit first looks up which of its own invoice and bill numbers the organisation already holds.

ActiveDetails

Transfer mechanism: The firm’s own agreement with Xero — blankit is not a party to it, and the data goes into the firm’s own books. Off by default, connected only by a firm administrator; the access credentials are encrypted at rest, and disconnecting stops all further processing. Listed for transparency rather than because blankit engages Xero: like the Intuit entry above, the contract is the firm’s.

Google (Drive)

Location: United States

Purpose: Only where a firm connects its own Google Drive as a claims-document folder. blankit polls the folder the firm nominates, downloads new PDFs for analysis, and — only if the firm enables the cleanup option — moves the processed source file to the folder’s trash after a retention window the firm sets.

Data: Whatever the firm places in that folder: carrier claims and renewal documents, which typically contain plan sponsor names and aggregate claims figures.

ActiveDetails

Transfer mechanism: The firm’s own Google Workspace agreement. blankit holds an OAuth grant to that one folder, not to the firm’s Drive at large; its credentials are encrypted at rest. Off by default, connected by a firm administrator, and revoking the grant stops all further processing. Deletion is to the provider’s trash — recoverable — never a hard delete.

Microsoft 365 and Google (mailboxes)

Location: United States

Purpose: Only where a firm OPTIONALLY connects its own mailbox to the evidence-of-insurability reply monitor. Carrier replies normally reach blankit by email at the firm’s own inbound address, with no mailbox connected and no data reaching either provider; where a firm does connect one, blankit reads that single inbox to match carrier replies to pending medical-underwriting submissions.

Data: The carrier’s reply message and its attachments, which may identify a plan member and reference a medical-underwriting decision.

ActiveDetails

Transfer mechanism: The firm’s own Microsoft 365 or Google Workspace agreement. The consent is scoped to the single mailbox that granted it — deliberately not the organization-wide variant, which would let the monitor read every mailbox in the tenant. Off by default, connected by a firm administrator, and revoking consent stops all further processing.

Cloudflare (Turnstile)

Location: Outside Canada. Cloudflare’s Turnstile privacy notice (last updated June 18, 2025) does not say where the signals are processed

Purpose: Telling a person from an automated script on blankit’s public forms (sign-up, contact, the demo) before they are submitted

Data: What Cloudflare’s notice lists: the visitor’s IP address, TLS fingerprint, browser user-agent, and the site key and origin. No client, plan-sponsor or plan-member data, and nothing typed into the form.

ActiveDetails

Transfer mechanism: Cloudflare’s Customer DPA (effective April 3, 2026). Cloudflare states it is a processor for the check itself, and a CONTROLLER of the same signals when it uses them to improve Turnstile’s bot detection. A cross-border transfer of the browser signals only.

Calendly

Location: The United States and other jurisdictions — Calendly’s Data Processing Addendum (effective June 1, 2026) says processing “will occur in the United States and other jurisdictions”

Purpose: Booking a call with blankit from the marketing site

Data: What a visitor types into the booking form — name, email and any note — and the time they choose. No client data.

ActiveDetails

Transfer mechanism: Calendly’s Data Processing Addendum and privacy notice (effective July 3, 2026); the visitor books directly with Calendly. A cross-border transfer of the booking details only.

Slack Technologies (blankit’s own support channel)

Location: The United States and other countries — Slack’s privacy policy (effective July 5, 2023) names transfers to Australia, Canada, Japan, India, South Korea and the United States

Purpose: Telling blankit’s support staff that an advisor has opened a help ticket, so it is answered quickly

Data: The ticket’s type and title, the firm’s name and plan, the page it was raised from, and a link back to the ticket. Never the description, a reply, a screenshot or any client data — those stay in blankit, stored in Canada. Advisors are asked to keep client names out of the title.

ActiveDetails

Transfer mechanism: Slack’s customer terms, held between Blankit Health Inc. and Slack. A cross-border transfer of the ticket summary only.

FreshBooks

Location: United States and Europe — on FreshBooks’ hosting providers, Google Cloud and Amazon Web Services, as FreshBooks’ own sub-processor list states; under FreshBooks’ own terms, and blankit does not choose it

Purpose: Only where a firm connects its own FreshBooks business. When someone at the firm presses Send on the Commissions page, blankit creates one draft invoice per carrier statement and, where the firm shares commission with outside co-brokers, one bill per co-broker per month. To avoid duplicates and use the right records, blankit first looks up the clients, bill vendors and expense category it needs, and which of its own invoice and bill numbers the business already holds.

ActiveDetails

Transfer mechanism: The firm’s own agreement with FreshBooks — blankit is not a party to it, and the data goes into the firm’s own books. Off by default, connected only by a firm administrator; the access credentials are encrypted at rest, and disconnecting stops all further processing. Listed for transparency rather than because blankit engages FreshBooks: like the Intuit and Xero entries, the contract is the firm’s.

Canada Post Corporation (AddressComplete, operated by GBG)

Location: Canada and the United Kingdom

Purpose: Address search on the Evidence of Insurability form, so a plan member can pick their mailing address instead of typing it

Data: The partial address a plan member types into the search box, and the address they choose. No name, date of birth, health information or any other field on the form is sent.

ActiveDetails

Transfer mechanism: Canada Post’s AddressComplete terms. A cross-border transfer: Canada Post may process the address search in the United Kingdom. Only the address search box is sent; the completed form, its health answers and the signature stay in blankit, stored in Canada.

BoldSign (by Syncfusion)

Location: Canada (BoldSign’s Canada data centre, Toronto)

Purpose: Electronic signature of the Evidence of Insurability form, and of the optional beneficiary designation, for optional Critical Illness coverage, and the signed record of each

Data: The completed form the plan member signs — including their answers to the medical questions, or the names, relationships and birth dates of the beneficiaries, insured family members and any trustee they name, with the member’s home address — their name and email address, and BoldSign’s record of the signing (time, IP address).

ActiveDetails

Transfer mechanism: BoldSign’s terms. BoldSign states that data for an account in its Canada data centre is stored and processed in that data centre. The signed form and BoldSign’s audit trail are copied back to blankit and stored in Canada, and blankit then deletes the form from BoldSign.

Amazon Web Services Canada (AWS End User Messaging — advisor text alerts)

Location: Canada (ca-central-1, Montreal)

Purpose: Urgent text-message alerts to advisors who have opted in: a renewal due within 7 days with no counter sent, an overdue renewal, or a carrier response — and the advisor’s own replies (YES to confirm, STOP to stop, HELP)

Data: The advisor’s mobile number and the text of each message, which names the plan sponsor (the client company), what needs doing and a link into blankit. No plan-member data, no premiums, claims or documents. The link opens only for someone signed in to blankit.

ActiveDetails

Transfer mechanism: Sent from Canada under the AWS Canadian Customer Agreement, then carried by the advisor’s own mobile carrier. Everything the link opens stays in blankit, stored in Canada. Off unless the advisor opts in and confirms their own number; at most three a day; STOP ends it at once. The advisor’s consent record stays in blankit.

Amazon Web Services Bedrock (AI processing)

Location: Requests enter AWS in Canada (ca-central-1, Montreal). AWS may process them outside Canada, including in the United States

Purpose: AI processing for every document type blankit reads and every AI feature it offers, using Anthropic’s Claude models hosted by AWS — carrier renewals, claims experience reports, coverage booklets, commission statements, carrier quotes and correspondence, Rider, and plan-member chatbot answers.

Data: Document content sent for reading — plan sponsor names, benefit and rate tables, aggregate claims figures, and booklet text. Plan-member questions and the booklet passages needed to answer them. A census or roster sent as a spreadsheet is parsed in code and never sent to an AI model; a census an advisor uploads as a PDF or photo is sent so its table can be transcribed — employee IDs, dates of birth, gender, province, salaries, classes and coverage, and any names printed on it (blankit keeps names only when the advisor turns them on).

ActiveDetails

Transfer mechanism: Storage and processing are two separate statements. Client data — documents, the database and backups — is STORED in Canada (AWS ca-central-1) and stays there. The AI PROCESSING of a request enters AWS in Montreal, and AWS may carry it out outside Canada, including in the United States, because Claude models on Bedrock are served through AWS cross-region inference. Disclosed as a cross-border transfer. Governed by the AWS Customer Agreement and the AWS Data Processing Addendum. AWS hosts the model; Anthropic does not receive the data on this path. blankit runs Amazon Bedrock with data retention set to “none” (zero data retention). AWS states that in this mode no request or response data is written to durable storage or shared with the model provider.

Anthropic PBC

Location: United States

Purpose: Developer of the Claude models blankit uses. In production those models are hosted by AWS Bedrock (above), and Anthropic does not receive blankit data.

Data: None. Requests go to AWS Bedrock, not to Anthropic.

Standby / fallbackDetails

Transfer mechanism: No transfer to Anthropic while AWS Bedrock is the configured path. Listed so a reader who sees “Claude” elsewhere on this site knows where it runs.

We're a sub-processor too — and we can't see your clients.

Blankit Health Inc. is the entity that operates the platform, so we are ourselves a processor under PIPEDA / Law 25. The platform admin role (currently held by the founder) is the operator identity that can step into a tenant for support. The relevant disclosure for your procurement review is what that role can and can't see.

The day-to-day product is single-tenant per firm — cross-firm reads are absent from the code paths your sessions touch. The exception is a read-only impersonation session the platform admin can start when a problem needs an engineer. Such sessions are:

Time-boxed to 30 minutes
Refused at the edge for any write, upload, delete, or message-send
Wrapped in a mask at the database extension that replaces client and contact names with deterministic pseudonyms (Client-XXXX), redacts emails / phone / policy numbers, and replaces document titles and free-text blobs with sentinels
Audit-logged at start and end with both operator and target identities

See Trust & security · Cross-firm access for the full mechanics and a live capture of what the operator actually sees on screen during a session.

We tell you before adding a sub-processor.

Firms that subscribe to blankit are notified at least 30 days before a new sub-processor is added to the production data path. Notification is emailed to the firm's billing and security contact and posted to this page.

A firm that objects to a new sub-processor within the 30-day window may terminate the subscription without penalty.

Privacy Officer: Chris Gory · privacy@blankit.ca

Last reviewed 2026-11-05. The internal source of truth is the Records of Processing Activities document (Blankit Health Inc., Section 3) — any change there is mirrored here in the same release.

See also: Privacy policy · Trust & security