SECURITY & PRIVACY / FOR YOUR BANK
Protecting customer information starts before the first assignment. Define where data is processed, who can access it, which actions are allowed, and how your bank will verify the result.
Dedicated bank-hosted deployments are scoped separately from the standard desktop product. On-premises hosting alone does not establish regulatory compliance or guarantee that information never leaves the bank.
Get the due diligence guide
CUSTOMER INFORMATION / IDENTITY & CYBERSECURITY
A Customer Identification Program (CIP) review asks who the customer is. A cybersecurity review asks how their information is accessed, handled, and protected. Bring both into a clear packet for the right bank reviewers.
IDENTITY EVIDENCE
Identity-verification result not supplied.
Route to the bank’s CIP reviewer. Do not infer that a document proves identity.CUSTOMER-INFORMATION PROTECTION
Document-sharing permissions not evidenced.
Route to the security owner. Missing evidence is not proof of a breach.Source references, open questions, and proposed follow-up go to the bank’s designated compliance and security owners.
LESS FILE ASSEMBLY. MORE TIME FOR REVIEW.
Where included in the agreed deployment, use Thaddeus to assemble a draft checklist from approved sources, link findings to evidence, and organize follow-up. Keep customer identifiers out of broadly shared summaries and preserve the original records.
“Using this synthetic onboarding packet and approved bank procedures, prepare separate CIP and customer-information-security checklists. Cite the evidence for each item, mark anything not supplied, and propose a reviewer for each open question. Do not contact the customer, verify identity independently, open an account, or change a bank record.”Review the bank’s information safeguards
EXAMPLE CASE / CIP-DEMO-01
Synthetic scenario: the packet includes placeholder intake fields, but no verification outcome or evidence of the document-sharing controls. No real name, account number, or identification document is used.
Disposition: bank review required. No account opened, credit decision made, records changed, or regulatory report filed.
Separate responsibilities, one coordinated review. CIP identity verification and cybersecurity controls serve different purposes. This illustration is not a complete CIP, a security assessment, or a compliance certification. The bank determines applicable rules, exceptions, verification timing, retention, and account handling under its written program. Customer due diligence, beneficial ownership, sanctions screening, and suspicious-activity obligations are separately scoped; they are not resolved by this diagram.
Reference points: FFIEC BSA/AML Manual: Customer Identification Program and OCC Bulletin 2021-36: authentication and access guidance (August 11, 2021). The CIP reference describes identifying information, risk-based verification, and records; the access guidance emphasizes risk assessment and layered safeguards. Use the requirements and guidance applicable to your institution.
Explore the customer-onboarding workflowAGREE ON THE REQUIREMENTS. ASK FOR THE EVIDENCE.
Start vendor due diligence with the proposed service, the information it can access, and the actions it can take. Match the evidence request to that scope. These are requirements to establish, not claims that every configuration already meets them.
01 / CUSTOMER-DATA BOUNDARY
Map inference, approved documents, retrieval indexes, prompts, answers, logs, backups, updates, and support exports. Test the agreed network restrictions and identify any external service dependencies.
02 / ACCESS & AUTHORITY
Define staff roles, source permissions, administration, and support access. Permission to read a document is not permission to email it, upload it, or share it externally. Test excluded information and prohibited actions.
03 / EVIDENCE & REVIEW
Check source passages, dates, conflicts, unsupported claims, and missing information. Agree on review criteria and keep consequential decisions with accountable bank personnel.
04 / RECORDS & RETENTION
Agree which activity is recorded, who may inspect it, how long it is retained, and how deletion and exports work. Confirm data-use restrictions in the applicable contract.
05 / CHANGE & SUPPORT
Assign responsibility for patches, model and software updates, evaluation after changes, rollback, and temporary support access. Establish how your bank approves each release.
06 / RECOVERY & CONTINUITY
Define incident response, backup and restore testing, recovery objectives, manual alternatives, and an exit path. Test capacity on the hardware proposed for your bank.
Begin with a read-only pilot and approved or synthetic inputs. Live customer data requires the bank’s security and risk review and expressly agreed written safeguards. Request the available assurance documentation and assess its actual scope; no certification or regulator approval is implied here.
Define your bank-hosted deploymentBANKING RESOURCE / SECURITY & DATA GUIDE
Evaluate the proposed service rather than a reassuring label. Trace information paths, examine vendor evidence, and distinguish customer identification from cybersecurity review.
THADDEUS WORKFLOW CAPABILITIES
These general Thaddeus capabilities support a supervised workflow. Confirm availability, access, and processing requirements in the dedicated bank deployment scope.
Supported connections bring business tools into the assignment with the account access and authorizations they require.
Plans, checkpoints, and delivery review give the assignment a defined scope and a result to compare with it.
A separate, persistent browser profile gives web work its own workspace, with user handoff so you can inspect or take over.
Keep core project state and generated files locally, with persistent plans, checkpoints, research, and results to support continuity.
Relay lets a paired phone inspect desktop progress, answer questions, approve actions, and stop work.
Source evidence, previews, delivery checks, and revisions give you material to inspect. They are not proof that an output is correct or ready to release.
Authorization has a scope. Your authorization can cover actions within an agreed scope; not every individual step is necessarily prompted again. Review the active permissions, allowed actions, and approval boundaries before delegating work.
Controls depend on the platform, release, accounts, permissions, and services involved. A plan supports scope discipline and verification; it does not eliminate every error, biased interpretation, or attack. Evaluate the workflow you intend to use.
The product page describes local storage of core project state and generated files. This helps define where that project material is kept.
Storage locationRequested AI, web, media, telephony, and connected-app operations may transmit relevant information to external services.
Processing & disclosureLocal-first does not mean entirely local. The standard desktop product can use external services for requested operations. A dedicated bank-hosted deployment has a separately agreed scope; confirm processing, network access, retention, and available features rather than transferring assumptions from one offering to the other.
Questions worth asking
Review connected accounts, requested permissions, and consequential actions. Product permission controls support supervision, but do not replace your organization’s access decisions and responsibilities.
Retention and permitted uses vary by provider, service, operation, and applicable agreement. The current privacy policy does not make a universal zero-retention or no-service-improvement promise for every provider. Review the applicable policy and agreement for the operation you intend to use.
Regulated or highly sensitive data needs expressly agreed written safeguards before submission. Do not infer banking, healthcare, residency, or compliance suitability from a local-storage description.
The standard desktop public beta is not an enterprise service-level agreement. A dedicated bank-hosted solution requires its own agreed scope for data handling, updates, support, recovery, and service commitments. Do not infer those terms from a desktop subscription.
A PRACTICAL FIRST EVALUATION
Begin with synthetic records and test accounts, not real customer information or sensitive business documents. Choose one bounded assignment and have a person supervise it before considering broader use.
Use this checklist as a discussion aid during your trial. Checking a box does not change product permissions or record an approval in Thaddeus.
A SERIOUS CONVERSATION ABOUT YOUR REQUIREMENTS
Your bank’s customer information, internal policies, and operational records deserve a review of the actual information path and commitments.
Identify the information involved, connected accounts, allowed actions, and people responsible for review. Confirm external processing, retention, deletion, and access requirements for each service.
Request the assurance documentation your organization needs. Establish applicable data-processing agreements, bank security requirements, deployment scope, and service commitments before using customer or regulated data.
Eligible exports carry no added Thaddeus watermark, so your work can use your branding. That does not remove metadata, service logs, license conditions, or legally required disclosure, and it does not guarantee anonymity.
Read the source
These published agreements describe the current desktop service. They do not replace the separately negotiated data handling, deployment, support, and service commitments for a dedicated bank-hosted solution.
Have specific requirements?
Describe your requirements without submitting sensitive data. Any custom safeguards, deployment option, or contractual commitment must be confirmed separately.
Discuss your requirements