List of Subprocessors

• Role: External AI inference through the Claude API. Protocol Wealth's applications call it through an API workspace operated under a Zero Data Retention (ZDR) agreement. Claude is used for:

  • Advisor chat and advisor tools on pwos.app, where it is the default model: research, analysis, drafting (including the firm's marketing and social posts) and document review for advisors, under human review, per the co-intelligence framework described in our Privacy Policy.
  • The client portal AI assistant on pwportal.app, a limited beta. It answers the signed-in client's questions about the client's own information directly. Its answers reach the client without advisor review, and it gives no investment advice. It is off for each client unless the client or an advisor switches it on, and either can switch it off.
  • Sorting inbound email. When the firm's rules cannot sort an email sent to one of its inbound addresses, Claude suggests a category, such as client, prospect, vendor or spam. The suggestion is stored for an advisor to accept or dismiss, and each saved suggestion is recorded in the audit log.
  • Internal backend tasks: titles for chat sessions, analysis of internal governance review items, summaries of the firm's operations, extraction of vendor compliance documents, and synthesis in the firm's internal research and operating-memory knowledge graphs, which admit content only through a de-identification check.
  • Work on the firm's own source code: repository tasks in the pwos.app agent console, whose task text is rejected if it contains personal information, and pull-request review.

• Data processed:

  • Advisor chat: Advisory content, plus Client PII and Financial data that the chat's tools retrieve, such as a client's profile or brief, KYC summary, performance, CRM records, and account and household detail. It also includes documents that advisors attach.
  • Advisor document review: the text of an agreement an advisor submits for review, which can name a client.
  • Portal assistant: the client's own messages, and the client's own accounts, balances, recent transactions and risk profile.
  • Inbound email sorting: the sender's name and email address, the subject, and up to about 2,000 characters of the body of an email sent to one of the firm's inbound addresses, after identifier replacement. Such an email can come from a client and can contain client information.
  • Internal tasks and code: the first message of a chat session, Firm operational data, de-identified research, and the firm's source code.

• Identifier replacement: Before content is sent, Protocol Wealth's pipeline replaces the identifiers it recognizes with placeholders. It does this in typed text, in tool results, and in Word, text and CSV attachments, in both advisor chat and the portal assistant, and in inbound email before it is sorted. For inbound email, if a separate outbound check still detects an identifier after replacement, nothing is sent and the email stays with staff for manual sorting. It does not remove personal information as a category, does not replace names, and is not relied on as if it did. It does not cover:

  • PDF and image attachments in advisor chat. These are sent to Claude as files and are not scanned.
  • The advisor document-review tool. It sends an agreement's text as written, because replacing names, figures and contact details would change the agreement's legal meaning. A separate outbound check logs the identifiers it detects there but does not remove them.
  • Chat-session titles. These are generated in the backend from the session's first message. The only check is a separate outbound check that refuses the request if it detects certain identifiers, such as a Social Security number.

  See "What the pipeline does and does not catch".

• Location: The firm's Anthropic API workspace is set to U.S.-only inference. Claude models from version 4.6 honor that setting. The firm's advisor, portal and backend services refuse to start with an older model.

• ZDR configuration: In place since April 2026 (owner, September 25, 2026). Zero retention of API inputs and outputs, U.S.-only inference, and exclusion from model training are set at the API workspace level. ZDR covers calls made through that workspace.

• Security attestations: Anthropic publishes these for the Claude API on its trust center: SOC 2 Type II, ISO 27001, ISO 42001, CSA STAR and NIST 800-171, and it offers a HIPAA business associate agreement. These are Anthropic's attestations, not Protocol Wealth's. FedRAMP High, DoD IL4/IL5 and ISO/IEC 27701 are not claimed for this service. Anthropic publishes its own subprocessors and current attestations at trust.anthropic.com. Protocol Wealth lists its direct subprocessors here and does not repeat Anthropic's.

• Protocol Wealth control layer: The two controls are independent. ZDR is a contractual control at Anthropic. Identifier replacement is a technical control at Protocol Wealth, and it reduces exposure without guaranteeing that none occurs.

• Role: Advisors can choose Grok as the model in advisor chat on pwos.app, since September 22, 2026. Claude remains the default, and an advisor can choose Grok (grok-4.7) for a conversation turn. Grok is also an option in the pwos.app marketing-copy writer, for the firm's own non-client material. It also works on the firm's own source code in three ways: repository tasks in the pwos.app agent console, whose task text is rejected if it contains personal information; code changes assigned to it through the firm's implementation tool; and pull-request review.

• Data processed: In advisor chat, Grok receives Advisory content. That includes Client PII and Financial data that the chat's tools retrieve, for example a client's profile, KYC summary, performance or CRM records, and it includes image attachments. Before transmission, the identifier-replacement pipeline used for Claude replaces the identifiers it recognizes in text with placeholders, such as Social Security numbers, account numbers, email addresses, phone numbers and dates of birth. It does not remove client names, and image attachments are sent as files without scanning. See "What the pipeline does and does not catch". A turn that carries a PDF document goes to Claude, not Grok. For marketing copy, Grok receives firm-authored material, with recognized identifiers replaced before sending. For code work, it receives Protocol Wealth's own source code (Firm operational data).

• Location: Advisor chat and the marketing-copy writer send requests only to xAI's U.S. regional endpoints: us-east-1 by default, with us-west-2 also permitted. A fail-closed allowlist in the firm's transport layer enforces this. A request addressed to any other host does not proceed.

• Data-handling posture: Zero data retention is contracted at the team level and has been active on Protocol Wealth's team since September 2026 (owner, September 25, 2026). The firm's API credential signs as that team. xAI asserts zero retention on every response with the x-zero-data-retention header. In advisor chat and the marketing-copy writer, Protocol Wealth's transport checks that header on every response and fails closed. A response without it is discarded rather than returned, and the turn fails. The check runs when the response arrives, after the request has been sent, so it cannot stop that request. It does make a change in retention posture visible at once. A credential moved to a different team, a change in team settings, or a silent vendor regression stops further use instead of passing unnoticed. xAI states that it never trains on API inputs or outputs without explicit permission. Under xAI's published terms, its default posture stores API requests and responses encrypted at rest for 30 days for abuse auditing and then deletes them. Under zero data retention, prompts and generated outputs are not written to disk. The firm accepts the operational cost of that choice. Under ZDR the following are unavailable to the firm: per-API-key request logging, the stateful Responses API, the Files, Collections and Batch APIs, deferred completions, and stored image, video and voice outputs.

• Security attestations: xAI's Trust Center lists an ISO/IEC 27001:2022 certificate (its scope includes SpaceXAI LLC's Grok API software services; Statement of Applicability, version 2.0, dated August 28, 2026) and a SOC 2 Type 2 report covering its Grok API. Protocol Wealth has viewed that SOC 2 report on the Trust Center but has not obtained a copy for its vendor file. A separate SOC 2 report xAI publishes covers a different X Corp system. The Trust Center also lists security controls; those are xAI's own statements, not audit evidence. These are xAI's attestations, not Protocol Wealth's. The engagement is governed by xAI's API and enterprise terms and data processing addendum for Protocol Wealth's zero-data-retention team, not xAI's consumer privacy policy, and it also rests on the per-response check described above.

• Governance: Grok has reviewed the firm's source code since August 14, 2026. Server-side routing to Grok in advisor chat was built on August 24, 2026. No advisor could select it until the model picker shipped on September 22, 2026.

One company, three services. Each is described below.

Google Cloud Platform

• Role: Primary compute and data platform for the firm's applications, including pwos.app, pwportal.app and the firm's API. Services used:
  • Cloud Run runs the applications.
  • Cloud SQL (PostgreSQL) holds their databases.
  • Memorystore (Redis) is their cache.
  • Cloud Storage holds files: attachments added to advisor chat, advisors' voice memos, documents the applications generate, and files uploaded through pwportal.app/upload while they wait for a malware scan.
  • Secret Manager holds credentials and keys.
  • Cloud Logging, BigQuery and Cloud Storage hold Google Cloud's audit logs of access to these resources.
  • Vertex AI runs the Gemini models described in the Google LLC (Gemini API) entry above.
  • Workload Identity Federation provides the pool the firm's CI/CD uses.
  • "Sign in with Google" on pwportal.app. A client who chooses it signs in with their own Google account through an OAuth client in the firm's Google Cloud project. Google authenticates the account and returns its email address and basic profile to Protocol Wealth. The portal admits only email addresses on its access list.
• Data processed: Client PII, Financial data, Advisory content and Firm operational data held in the firm's applications are stored on GCP or pass through GCP compute. Google encrypts stored data by default (AES-256) with Google-managed keys; the firm does not use customer-managed keys. Connections from the applications to Cloud SQL and Memorystore require TLS, and neither has a public IP address.
• Location: United States. The firm's regional resources are in us-central1 (Iowa). A few, such as the audit-log dataset in BigQuery, use Google's U.S. multi-region. Since September 24, 2026, the organization policy gcp.resourceLocations has allowed new resources to be created only in U.S. locations (in:us-locations) across the firm's Google Cloud organization. The policy does not move existing resources, and it does not apply to global resources such as load-balancer addresses. Secrets created before the policy use Google's automatic replication, whose locations Google chooses; they hold credentials and keys, not client records. Secrets created since then replicate to us-central1 and us-east5 (Ohio).
• Security attestations: As published by Google: SOC 1, SOC 2 and SOC 3 reports; ISO/IEC 27001, 27017, 27018 and 27701; PCI DSS; FedRAMP High; and a HIPAA business associate agreement is available.

Gemini AI models, through Google Cloud's Vertex AI

This entry covers Protocol Wealth's use of Google's Gemini models specifically. It is distinct from the Google Cloud Platform and Google Workspace infrastructure entries below.

• Role: Generative AI through Google's Gemini models, in roles that are not client-facing:

  1. Image and graphics generation for advisor workflows, including accompanying text. This runs in the advisor graphics studio on pwos.app and in an image-generation tool in advisor chat.
  2. Search indexing of documents added to advisor chat. Sometimes an advisor asks for a section of such a document and the section cannot be found by heading, clause reference or keyword. The first time that happens for a document, its text is split into passages and sent to the gemini-embedding-001 embedding model. The numeric vectors returned are stored in Protocol Wealth's systems for later retrieval.

  Calls for these two roles are brokered through Protocol Wealth's backend (pw-api). There is no client-facing Gemini surface. 3. Embeddings for the firm's internal knowledge graphs: a research graph and an operating-memory graph. Both admit content only through a fail-closed de-identification check. These services call Gemini directly rather than through pw-api.

• Data processed: For graphics generation, prompts from advisor workflows and the generated output. For search indexing, passages of documents added to advisor chat, which can include client information (Client PII, Financial data). For the knowledge graphs, de-identified research and the firm's own operating notes (Firm operational data). Brokered requests pass through the same identifier-replacement pipeline and fail-closed egress check that apply to Protocol Wealth's other external AI traffic. That pipeline replaces the identifiers it recognizes with placeholders. It does not remove personal information as a category, it does not remove names, and it is not relied on as if it did. See "What the pipeline does and does not catch".

• Terms: Since September 23, 2026, brokered calls go to Gemini through Vertex AI under the firm's Google Cloud agreement. They authenticate as the firm's own service account and use no API key. Google Cloud's Service Specific Terms include a Training Restriction: Google will not use customer data to train or fine-tune any AI/ML model without the customer's permission or instruction.

• Location: Brokered calls go to Vertex AI's U.S. endpoints: the us multi-region and us-central1. This statement does not cover the knowledge-graph services' calls.

• Security attestations: Google publishes SOC 1, SOC 2 and SOC 3 reports and ISO/IEC 27001, 27017, 27018 and 27701 certifications across its cloud services. These are Google's attestations, not Protocol Wealth's.

Google Workspace

• Role: Firm-wide productivity, collaboration, and communications suite for Protocol Wealth personnel. Google LLC provides it under a single Google Workspace enterprise agreement and Data Processing Amendment (one Workspace DPA, not a separate contract per product). Services used: Gmail (business email), Google Calendar (scheduling), Google Drive (document storage), Google Docs / Sheets / Slides (document authoring), Google Meet (video conferencing), Google Voice (business telephony: inbound and outbound calls, text/SMS messaging, and voicemail), and Google Vault (retention, legal hold, and eDiscovery across the above). Firm personnel sign in to pwos.app with their Workspace accounts.
  • Client records in Drive. Google Drive holds client records in firm-controlled folders and shared drives:
    • documents that pwos.app files for clients;
    • Docs, Sheets and Slides that advisor chat on pwos.app creates at an advisor's request, in the firm's designated pwos.app folders;
    • files that clients and prospects upload through pwportal.app/upload, placed in an internal shared drive after a malware scan;
    • since September 22, 2026, the daily Schwab custodial data packages Nexhelm delivers. Account numbers in them are masked to the last four digits. The packages can include account names and registration details (see the Nexhelm entry).
  • Advisor chat. Acting as the signed-in advisor, advisor chat on pwos.app can search that advisor's Gmail, read Drive files and calendar events, and create Gmail drafts (not sent mail) and calendar events.
  • Portal sign-in. Workspace is not used to authenticate clients to the client portal. A client who chooses "Sign in with Google" signs in with their own Google account; see the Google Cloud Platform entry.
• Data processed:
  • Firm operational data, including communications data: the content and metadata of firm calls, text messages and voicemails handled through Google Voice, together with advisor email and calendar data.
  • Client PII and Financial data held in the client records described above.
  • Client PII in advisor email correspondence, calls, messages, calendar entries and internal documents.
• Location: Google's data centers. Google's Workspace data processing terms allow Google to process data in any country where Google or its subprocessors maintain facilities. Protocol Wealth has not confirmed that a U.S. data region is set for its Workspace account, so this list does not state one.
• Security attestations: As published by Google: SOC 1, SOC 2 and SOC 3 reports; ISO/IEC 27001, 27017, 27018 and 27701; and a HIPAA business associate agreement is available.

• Role:
  • DNS for Protocol Wealth's domains.
  • Hosting and content delivery, through Cloudflare Pages, for the firm's public websites, including protocolwealthllc.com and pwinsights.com. The website's contact, assessment and diagnostic forms are handled by code that runs on Cloudflare's network, so Cloudflare processes what a visitor submits before it reaches Protocol Wealth's own systems. Protocol Wealth's advisory platform accepts a submission from the website only when it carries a valid signature from that code, and records it as a prospective-client inquiry.
  • Cloudflare Access controls sign-in by firm personnel to an internal monitoring tool. That tool holds usage metrics and opaque identifiers, not client content.
  • Protocol Wealth reads aggregate traffic statistics for its public websites from Cloudflare.
  • Not routed through Cloudflare. Cloudflare answers DNS lookups for the advisory platform (pwos.app), the client portal (pwportal.app) and the webhooks endpoint (webhooks.protocolwealthllc.com), but their traffic goes directly to Google Cloud and does not pass through Cloudflare's network. The pw-api data service is private (internal ingress only) and is not reachable from the internet.
• Data processed:
  • Personal information of prospective clients and other website visitors: whatever a visitor enters in the website's forms, such as name, email address, telephone number and company, and scores from the website's assessment and diagnostic tools.
  • Website traffic metadata, including visitor IP addresses, and DNS query metadata.
  • Firm operational data: the sign-in identity of firm personnel using the monitoring tool.
• Location: Cloudflare's global network. A website request or DNS query is handled at a Cloudflare data center near the visitor, which may be outside the United States.
• Security attestations: Cloudflare's published attestations: SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27701, PCI DSS Level 1.
  • Protocol Wealth's own settings, which are configuration and not attestations: protocolwealthllc.com accepts HTTPS only, at TLS 1.3 minimum, with HSTS and strict certificate validation to the origin. The firm's Cloudflare account requires two-factor sign-in.

• Role: Identity verification for a client when an advisor turns it on. Since August 2026, identity verification is off by default. An advisor turns it on for a particular client when the situation calls for it. When it is on, the client photographs a government-issued ID and takes a selfie in Veriff's own verification screen, embedded in the client portal. Veriff checks the document, confirms that a live person is present and compares the face with the ID photo. Protocol Wealth also requests Veriff's politically-exposed-person and sanctions watchlist screening result for the session.

• Data processed: Client PII:

  • government-issued ID document images and the details Veriff reads from them, such as name, date of birth and document number;
  • selfie and liveness captures, and the facial comparison between the selfie and the ID photo (a biometric check);
  • the verification decision and the watchlist screening result.

  To start a session, Protocol Wealth sends Veriff only an internal reference number, not the client's name or other identifiers. Veriff's notifications to Protocol Wealth are signed, and Protocol Wealth verifies the signature before acting on them.

• Location: Veriff OÜ is headquartered in Estonia. Where Veriff processes and stores this data is not confirmed.

• Security attestations: Veriff's published attestations: SOC 2 Type II and ISO/IEC 27001.

• Role: Compliance platform and records archive. Protocol Wealth keeps the master copy of its compliance records in Hadrius, including the Form ADV and the compliance manual, and Hadrius holds the firm's email and social-media archives. The firm also uses its AI-assisted compliance review of firm communications and marketing materials. Protocol Wealth's applications have no programmatic connection to Hadrius. Compliance records produced in the firm's own systems are transferred to it by hand.
• Data processed: Firm operational data: archived firm email and social-media communications, marketing materials, and compliance records. Client PII, and any Financial data or Advisory content, is included to the extent it appears in archived client correspondence or in compliance records filed there.
• Location: Where Hadrius processes and stores this data is not confirmed.
• Security attestations: Protocol Wealth has not confirmed a vendor-published security attestation for Hadrius.

• Role: Financial account aggregation platform. Clients link accounts they hold at other financial institutions through Quiltt's Connector, which is embedded in the Protocol Wealth client portal, and Protocol Wealth retrieves the linked accounts' data from Quiltt's API. Protocol Wealth has a single integration and contract with Quiltt, and Quiltt provisions the downstream providers for that integration: MX and Finicity for financial-institution connectivity, and FinGoal for transaction enrichment. Protocol Wealth holds no contract with any of them and does not assess any of them separately. Quiltt is the assessed and contracted party. Quiltt routes each institution connection to MX or Finicity and can move a connection from one to the other.
• Data processed: Client PII and Financial data. To set up account linking, Protocol Wealth sends Quiltt the client's full name and email address, with an internal profile identifier and technical routing tags. The client signs in to each financial institution inside Quiltt's Connector, and Protocol Wealth does not receive the client's institution sign-in credentials. For the accounts the client links, Protocol Wealth retrieves from Quiltt the institution name; each account's name, type, masked account number and balances; investment holdings (security name and identifiers, quantity, price, cost basis and value); and transactions (date, amount, description and status) with FinGoal's enrichment (merchant name, category and a recurring-transaction flag). Linked accounts can include credit-card and loan accounts, for which Protocol Wealth retrieves balances and transactions. Protocol Wealth's integration does not request Quiltt's separate liabilities data product. Typical flow: financial institution → MX or Finicity (connectivity) → Quiltt → Protocol Wealth, with FinGoal enrichment applied through Quiltt.
• Location: United States.
• Security attestations: Quiltt's published attestation is a SOC 2 Type II report (auditor Insight Assurance; examination period November 1, 2024 to January 31, 2025; Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality). Quiltt gates access to the report through its trust center at trust.quiltt.io. The governing contract is the Quiltt Master Services Agreement. It provides that end users own their data, that customer data is deleted within 15 days of termination, and that Quiltt notifies the customer of a breach within 24 hours.

• Role: Financial-institution connectivity provider. MX is reached through Quiltt and is currently active. Quiltt routes each institution connection to MX or Finicity. Protocol Wealth uses MX for connectivity only; the transaction enrichment Protocol Wealth reads comes from FinGoal, not MX. Protocol Wealth does not integrate directly with MX, and MX data reaches Protocol Wealth only through the Quiltt platform.
• Data processed: The institution sign-in the client completes in Quiltt's Connector, and the data of the accounts linked through that connection, including account names and types, balances, transactions and investment holdings.
• Location: United States.
• Security attestations: Protocol Wealth's assessed and contracted vendor for this data flow is Quiltt. See the Quiltt entry for the governing Master Services Agreement and Quiltt's SOC 2 Type II report. Quiltt provisions MX for Protocol Wealth's integration, so Protocol Wealth holds no contract with MX and does not separately assess MX's attestations.

• Role: Financial-institution connectivity provider. Finicity is reached through Quiltt and is currently active alongside MX. Quiltt routes each institution connection to Finicity or MX and can move a connection between them. Protocol Wealth does not integrate directly with Finicity, and Finicity data reaches Protocol Wealth only through the Quiltt platform, under the Quiltt Master Services Agreement.
• Data processed: The institution sign-in the client completes in Quiltt's Connector, and the data of the accounts linked through that connection, including account names and types, balances, transactions and investment holdings.
• Location: United States.
• Security attestations: Protocol Wealth's assessed and contracted vendor for this data flow is Quiltt. See the Quiltt entry for the governing Master Services Agreement, Quiltt's SOC 2 Type II report and the agreement's breach-notice terms. Quiltt provisions Finicity for Protocol Wealth's integration under that agreement, so Protocol Wealth holds no contract with Finicity and does not separately assess Finicity's attestations. MX is documented on the same basis.

• Role: Transaction enrichment provider routed through Quiltt. It is currently active and is the firm's sole enrichment provider. Protocol Wealth does not integrate directly with FinGoal and holds no contract with it. FinGoal's output reaches Protocol Wealth only through the Quiltt platform.
• Data processed: Transaction-level data for the accounts clients link through Quiltt, such as the amount, date and description of each transaction. For each transaction, FinGoal returns a merchant name, a category, a short plain-language description and a flag for recurring transactions. That enrichment reaches Protocol Wealth attached to the transactions Quiltt delivers.
  • Not included: FinGoal also offers profile-level insights through Quiltt. Protocol Wealth does not retrieve or use them. Protocol Wealth classifies transactions for cash flow itself (income, expense, transfer or credit-card payment), and advisors can override that classification. It is not a FinGoal output.
• Location: United States.
• Security attestations: Protocol Wealth's assessed and contracted vendor for this data flow is Quiltt. See the Quiltt entry for the governing Master Services Agreement, the SOC 2 Type II report and the breach-notification terms. Quiltt provisions FinGoal on Protocol Wealth's behalf under that agreement, so Protocol Wealth does not separately assess FinGoal's attestations, and its vendor diligence file holds no FinGoal attestation report. Quiltt's vendor-management obligations under the Master Services Agreement cover the providers it provisions. The Finicity entry is documented the same way.

• Role: Financial planning software. Protocol Wealth's advisors build and maintain client plans in it. The firm uses it today for retirement planning, concentrated-stock analysis and secure document upload. For planning engagements, Protocol Wealth's Client Advisory Agreement provides that the written plan and implementation checklist are delivered "directly via email, or through the RightCapital platform or other similar online platforms," and that the service "includes client access to RightCapital or similar online platform for financial modeling and portfolio analysis." RightCapital also holds an authorization to read Protocol Wealth's Wealthbox CRM.
  • Replacement: Protocol Wealth is building planning tools in its own platform to replace RightCapital. RightCapital is in use today.
• Data processed: Client PII and Financial data: the inputs a plan is built from (household composition, income, expenses, account balances and holdings, goals, insurance and tax assumptions) and the plan output itself. It also holds documents uploaded through its secure document-upload feature.
• Location: United States.
• Security attestations: Protocol Wealth's vendor diligence file, indexed in the firm's vendor register, holds these documents from RightCapital: a SOC 2 report (Standard Package) for the period ending June 30, 2023; an information security policy; a penetration-test letter of attestation (2024); a compliance due-diligence information sheet (April 2024); a 2023 FINRA review letter; and a certificate of insurance.

• Role: Operates Schwab OpenView Gateway, the data-delivery service through which Schwab account data reaches Wealthbox, the firm's CRM. Under the Gateway Advisor Enrollment Use Agreement, data the firm requests for delivery, including data about client accounts at Charles Schwab & Co., Inc., is replicated and maintained in a database at Schwab Intelligent Technologies before delivery to the enrolled product. Protocol Wealth enrolled on August 27, 2026, with Wealthbox as the enrolled product. Account balances and position detail are delivered to the CRM record of the matching client.
  • No direct integration: Protocol Wealth's own systems do not connect to the Gateway. This data reaches them only when an advisor copies position detail out of Wealthbox into the firm's platform.
• Data processed: Client PII and Financial data (account balances and position detail) for accounts custodied at Charles Schwab & Co., Inc. Typical flow: Charles Schwab & Co., Inc. → Schwab Intelligent Technologies (replica database) → Wealthbox.
• Location: United States. The enrollment agreement does not itself specify processing regions. The entity is a United States company and a subsidiary of The Charles Schwab Corporation.
• Security attestations: A subsidiary of The Charles Schwab Corporation (NYSE: SCHW). Per the Gateway Advisor Enrollment Use Agreement, it is affiliated with Charles Schwab & Co., Inc. as a separate subsidiary of the same parent. That agreement governs this engagement and allocates responsibility explicitly: Schwab Intelligent Technologies disclaims responsibility for the enrolled product's privacy policy, data security measures and use of subcontractors, and caps its own aggregate liability at one hundred dollars. Diligence on the enrolled product is therefore Protocol Wealth's, and it is carried under the Wealthbox entry on this list. Protocol Wealth holds no service-organization control report for Schwab Intelligent Technologies, and obtaining one is an open diligence item.

Classification note: Schwab Intelligent Technologies is listed separately from Charles Schwab & Co., Inc. because it is a distinct legal entity that maintains its own replica of client account data, even though the two are affiliated subsidiaries of the same parent. Listing the replica holder, not only the custodian, more accurately discloses where client data rests.

• Role: Delivers the Charles Schwab & Co., Inc. custodial data for the accounts Protocol Wealth advises. The service is currently active.

  • Delivery: a read-only daily data package of JSON files: a manifest, accounts, positions, balances, cost basis and transactions. Data is one business day behind the source.
  • Account numbers: Nexhelm masks each account number to its last four digits before it delivers a package. Nexhelm confirmed this on September 24, 2026, and Protocol Wealth checked it against a delivered package on September 25, 2026.
  • Where it lands: Nexhelm places each package in a Google Workspace shared drive that Protocol Wealth set up for this delivery. Nexhelm's access is to that shared drive only. The package files stay in that drive as delivered, and their account records include account names and registration lines (see the Google Workspace entry).
  • What Protocol Wealth's platform keeps: when the platform loads a package, it reads it with read-only access to the drive. For each account it keeps the last four digits of the account number, Nexhelm's opaque account identifier (which is not the account number), and the account type and status. For accounts linked to a client, it also keeps positions, balances and cost basis. It keeps no other form of the account number.
  • Not included: no trading, no account changes, no workflow execution, and no two-way control of any account.
  • First delivery: September 22, 2026. It contained all six files.
  • Source: Nexhelm obtains the data through Bridge Financial Technology, Inc. (BridgeFT), listed below. Charles Schwab & Co., Inc. remains the custodian and the source of the data (named on the custodians line above); it is not Nexhelm's subprocessor.
  • Contracts: a Cloud Service Agreement and a Data Processing Agreement, both signed September 15, 2026, and a Design Partner Agreement signed the same day.

• Data processed: Client PII and Financial data for accounts custodied at Charles Schwab & Co., Inc. Per Nexhelm's Subprocessor List (v1.0, effective September 21, 2026), Nexhelm processes:

  • account names and numbers, registration and account types, and mailing addresses where Schwab supplies them;
  • positions, balances, transactions, cost basis, and realized gain or loss;
  • the firm's advisor and master account codes.

  Account numbers leave Nexhelm masked to their last four digits. Typical flow: Charles Schwab & Co., Inc. → BridgeFT → Nexhelm → a firm-controlled Google Workspace shared drive → Protocol Wealth.

• Location: United States. Nexhelm's application and scheduled jobs run on Amazon Web Services (us-east-1). The data at rest is held in Supabase (managed PostgreSQL, on AWS us-west-1). Nexhelm's Subprocessor List names both as Nexhelm's own subprocessors, engaged by Nexhelm under its contracts. They are not parties to any contract with Protocol Wealth.

• Data-handling posture:

  • No AI in this data path. Nexhelm states that no AI model is called and that the data is not sent to a tracing or analytics service.
  • Nexhelm's other vendors. Nexhelm's web application uses Vercel, Sentry and Statsig. Its AI-assisted workflows use LangSmith, Google, OpenRouter, Anthropic, Azure OpenAI and Tavily. These would process firm data only if the firm used Nexhelm's web application or an AI-assisted workflow. This engagement uses neither.
  • Retention. Per Nexhelm's written answers of September 21, 2026, the data is kept while the service runs and deleted within 30 days after the agreement ends, with written certification.
  • Training. Nexhelm states that it does not train models on customer data and that the agreement says so.
  • Subprocessor changes. Nexhelm states that it gives at least 30 days' written notice before adding or replacing a subprocessor, and that Protocol Wealth may object.

• Security attestations:

  • Nexhelm's SOC 2 Type II report, from auditor Zero Day CPA, PC, is dated March 6, 2026, and covers the period 2025-11-01 to 2026-01-31 against the Security Trust Services Criteria, with an unmodified opinion.
  • Nexhelm's bridge letter dated September 15, 2026 states that there have been no material changes since the end of that period.
  • Protocol Wealth's vendor diligence file holds the report and the bridge letter; both signed agreements; Nexhelm's Data Protection, Data Retention and Encryption policies; its Subprocessor List v1.0; and its written answers of September 21, 2026. The file is indexed in the firm's vendor register.

• Role: Custodial data aggregator engaged by Nexhelm. It is currently active.
  • How it gets the data. Protocol Wealth authorized Schwab to deliver the firm's account data to BridgeFT by submitting a Request for Data Access.
  • What it does. BridgeFT normalizes that data and makes it available to Nexhelm.
  • Contract. BridgeFT is Nexhelm's subprocessor. Protocol Wealth has no services agreement with BridgeFT and does not integrate with it directly. BridgeFT data reaches Protocol Wealth only through Nexhelm.
• Data processed: The same Client PII and Financial data described in the Nexhelm entry above, for accounts custodied at Charles Schwab & Co., Inc. Protocol Wealth's systems send BridgeFT no data.
• Location: BridgeFT is a U.S. company. Protocol Wealth has not confirmed where BridgeFT processes this data.
• Security attestations: Protocol Wealth's contracted vendor for this data flow is Nexhelm. See the Nexhelm entry for the governing agreements and Nexhelm's SOC 2 Type II report.
  • What Nexhelm says. Nexhelm's Subprocessor List describes BridgeFT's attestation details as under review for Nexhelm's vendor file and available on request.
  • What the firm holds. Protocol Wealth holds no BridgeFT attestation report.
  • Open diligence item. Obtaining that attestation through Nexhelm is an open item. While it is open, the general statement under "Which companies are on this list" (that the contracted vendor's obligations cover the providers it engages) does not apply to BridgeFT.

• Role: Multi-party computation (MPC) wallet platform. A client's digital assets on Fordefi sit in the client's own Fordefi workspace. Protocol Wealth is a member and a signer in each client workspace, and changes to a workspace's administration or policy need the client's approval. Protocol Wealth's own Fordefi workspace holds only the firm's and its founders' wallets, and no client assets. Fordefi is wallet technology, not a qualified custodian.
• Data processed: For client workspaces: workspace membership, including Protocol Wealth's users; wallet addresses; balances and transaction data; and the transactions Protocol Wealth proposes or signs.
• Location: US and Israel, with US-region processing for Protocol Wealth workloads.
• Security attestations: SOC 2 Type II, as Fordefi publishes it.

• Role: Backup and recovery for Fordefi MPC key material. Each client completes Coincover's own process. Coincover keeps an encrypted backup of the Fordefi private keys, and the decryption key can be delivered only to the client. Protocol Wealth cannot receive the decryption key.
• Data processed: The client's identity and contact details, for Coincover's own verification process, and the encrypted backup of the Fordefi key material.
• Location: United Kingdom.
• Security attestations: ISO 27001 and SOC 2 Type II, as Coincover publishes them.

• Role: Business banking platform for Protocol Wealth's operating accounts.
  • Client fee payments. Fees that clients pay Protocol Wealth directly, rather than by debit from a custodial account, arrive in these accounts. Protocol Wealth bills some clients' fees through Mercury's recurring invoicing.
  • Platform integration. Protocol Wealth's platform reads the firm's Mercury accounts and transactions through Mercury's API. The read runs when firm personnel start a sync from the firm's internal finance page; it is not scheduled. The platform uses the data for expense tracking and to match client fee payments to the fees expected from each client. Firm personnel confirm each match.
  • Read-only. The integration makes no payment or transfer requests. The API token is read-only by design and carries no payment or transfer scope. Protocol Wealth's platform sends Mercury no client data.
• Data processed:
  • Firm operational data: the firm's own operating-account balances, transactions, statements and counterparty details.
  • Client PII and Financial data related to fees. For fees clients pay the firm directly, this is the payer's name, the amount, the date and any payment memo. For clients billed through Mercury's recurring invoicing, it is the invoice recipient's details and the fee amount.
• Location: Mercury is a U.S. company. Protocol Wealth has not confirmed where Mercury processes this data.
• Security attestations: Protocol Wealth's vendor review of Mercury is open, and this list states no attestation for Mercury.

• Role: Customer relationship management (CRM). The advisory team keeps client and prospective-client records in Wealthbox: contacts, households, notes, tasks, opportunities, projects and workflows.
  • Access: Protocol Wealth's systems connect to Wealthbox only from its servers. The access key is held by one internal service and never reaches a web browser.
  • Advisor chat: the advisor assistant in the firm's advisor platform (pwos.app) can read Wealthbox records. Each change it proposes, such as a new note or task, is shown to the advisor as an exact preview and is made only after the advisor confirms it in a new message.
  • Newsletter and webinar sign-ups: new newsletter subscribers and webinar registrants are added to Wealthbox as contacts. This sync only creates a contact or matches an existing one. It does not change or delete any Wealthbox record.
  • Schwab account data: Schwab OpenView Gateway delivers account balances and position detail for accounts at Charles Schwab & Co., Inc. into the matching Wealthbox contact records. See the Schwab Intelligent Technologies entry.
• Data processed:
  • Client PII for clients and prospective clients: names, email addresses, phone numbers, street addresses, dates of birth, household relationships and tags.
  • Nonpublic personal information the firm keeps in Wealthbox custom fields: tax filing status, number of dependents, IRS backup withholding, control-person status and FINRA affiliation.
  • Advisory content and workflow records: advisor notes, tasks, opportunities, projects, workflows and calendar events.
  • Financial data: account balances and position detail for Schwab-custodied accounts, delivered through Schwab OpenView Gateway.
  • For newsletter subscribers and webinar registrants: name, email address and, where given, city, state, postal code and country.
• Location: United States. Wealthbox's privacy policy states that data is stored on servers located in the USA. Wealthbox is hosted on Amazon Web Services.
• Security attestations: Wealthbox states publicly that it is a SOC 2 Type 2 certified organization. It does not publish the auditor or the report period, and makes the report available on request. Protocol Wealth's vendor file holds Wealthbox's Information Security Policy, Business Continuity Plan and Incident Management Plan.

• Role: Email delivery for Protocol Wealth's systems, and processing of email sent to the firm's inbound email addresses.
  • System email: portal sign-in links; access links and codes for identity verification and secure document upload; onboarding invitations; webinar confirmations; and notices to advisors, for example that a client sent a message or uploaded a document.
  • Newsletters and webinar sequences: newsletter broadcasts and webinar follow-up email, sent on a separate Postmark message stream.
  • Chat exports: an advisor can email a PDF export of an advisor chat conversation.
  • Inbound email: Postmark receives email sent to the firm's inbound addresses and passes each message to pwos.app, where it is filed for advisor review. These messages can come from clients.
  • Delivery events: Postmark reports delivery, bounce and similar events back to Protocol Wealth.
• Data processed:
  • Client PII: the names and email addresses of recipients, who include clients, prospective clients, newsletter subscribers and webinar registrants.
  • The contents of the messages above. Sign-in and access links and codes are short-lived credentials. Portal sign-in links work once and expire about an hour after they are sent.
  • Messages that clients send through the client portal, relayed to advisors by email with recognized identifiers replaced. Names are not replaced (see "What the pipeline does and does not catch").
  • Advisory content, when an advisor emails a chat export.
  • Inbound email in full: sender, recipients, subject, body and attachments. It can contain anything the sender includes, including Client PII and Financial data.
  • Delivery and bounce events.
• Location: United States. Postmark's primary data center is outside Chicago. Postmark also uses Amazon Web Services and does not publish the region.
• Security attestations: Postmark states that it has not itself undergone a SOC audit, and that its data centers have. Its parent company, ActiveCampaign, makes a SOC 2 Type II report available through its trust center.

• Role: Electronic signature of the Client Advisory Agreement. Since August 2026, Protocol Wealth sends client agreements for signature through Charles Schwab's DocuSign integration, which the firm uses through Schwab. The advisor then uploads the executed PDF, and Protocol Wealth keeps it in its own systems.
• Data processed: Client PII: signer names and email addresses; the agreement's contents, which include the client's legal name, email and mailing address, the services elected and the fees; signatures; and the signing-event record DocuSign keeps for each envelope.
• Location: DocuSign, Inc. is a U.S. company.
• Security attestations: DocuSign publishes its attestations at its trust center.