Privacy Policy
TitleBridge sits between a title company's Qualia workspace and the systems that need to see order status. This policy explains what we store, what we deliberately refuse to store, and how the sensitive parts of a title file are handled.
We are a hosted service, so title order data does pass through and rest on our systems. But the sensitive part of a title file — borrower identity, property address, loan and policy amounts, and the curative report — is never written to our database. It's filtered out before storage by an allowlist, and shown only by fetching it live from Qualia at the moment someone with permission asks to see it.
What we hold day to day is the status layer: order numbers, milestones, dates, business names, and staff contact details — plus the lender loan number, which we must store to match records and therefore keep encrypted.
1. Who we are and our role
TitleBridge ("TitleBridge", "we", "us") operates a hosted service that reads title order data from a title company's Qualia workspace, keeps a timeline of every change, and forwards status updates to approved destinations such as a lender's Salesforce org.
We act in two different capacities, and which one applies changes what rights you have and who you should ask:
| Role | When it applies |
|---|---|
| Processor (service provider) | For title order data. The title company is the controller — it decides what we process and why, under a written agreement. Requests about a specific transaction go to them, not to us. |
| Controller | For our own business contacts: website visitors, demo and contact enquiries, portal user accounts, and support correspondence. |
Where a customer agreement or data processing agreement covers the same subject matter, that agreement governs and this policy fills the gaps.
2. What this policy covers
- This website, including the demo and contact forms.
- The TitleBridge portal, where title company staff and our team review orders, timelines, and connections.
- The ingestion and delivery services that read from Qualia and push updates to connected destinations.
- Email, calls, and support correspondence with our team.
It does not cover Qualia, Salesforce, or any other system you connect. Those are governed by your own agreements with those providers.
3. How order data is handled
Our handling of title data is a deliberate architectural choice rather than a policy promise, so it's worth describing plainly.
Every payload we read from Qualia passes through a storage allowlist before anything reaches our database. Fields are classified into three buckets, and only the first two are ever written:
| Classification | Treatment |
|---|---|
| Stored | Structural and status information with no personal financial content — order numbers, milestones, dates, business entity names. |
| Stored, isolated | Staff contact details — settlement team members, loan officer and brokerage contacts. Business-context personal data, walled off per customer. |
| Never stored | Consumer nonpublic personal information. Filtered out before storage and fetched live only when someone authorised asks to see it. |
Two properties of this design matter more than the list itself:
- It's an allowlist, not a blocklist. A field Qualia introduces tomorrow is dropped by default rather than silently persisted. New fields have to be reviewed and opted in.
- It fails closed. If the filter cannot parse a payload, it degrades to a minimal identity record and raises an alert. It never falls back to storing the unfiltered payload.
Free text that survives filtering is additionally scanned and scrubbed for Social Security number patterns.
4. What we store
| Category | Examples |
|---|---|
| Order identity | Qualia order ID, order number, external reference number. |
| Status | Current status, status summary, purpose, transaction type, product flags such as HELOC or cash-only. |
| Milestones | Task and milestone names, group names, completion flags and timestamps, due dates. |
| Dates | Origin, created, contract, funding, consummation, disbursement, cancellation, last modified. |
| Business names | Underwriter, lender, and brokerage entity names; workflow and order template names; fee line structure and business payee names, without amounts. |
| Commitment exceptions | Standard boilerplate policy exceptions, which contain no party-specific detail. |
| Staff contacts | Settlement team and brokerage staff names and work email addresses, isolated per customer. |
| Loan number | The lender loan number — see below. |
The loan number, and why it's the exception
The lender loan number is the key that matches a title order to the right record in a lender's system. It cannot be filtered out without breaking the product, so we store it — and treat it as the single deliberate exception rather than a reason to relax the rule elsewhere:
- Encrypted at rest with AES-256-GCM, as its own protected field rather than as ordinary column data.
- Searched through a separately-keyed blind index, so lookups work without decryption and the search key alone cannot reveal loan numbers.
- List views show only whether a loan number is present. Decrypting one to display it writes its own audit record.
5. What we never store
The following are stripped before storage and appear in no table, no cache, no backup, and no log file:
- Borrower and party identity — names, email addresses, phone numbers, and other contact details of consumers on the transaction.
- Property address and parcel identifiers tied to the transaction. We keep only the state, which we use for turn-time measurement.
- Loan amounts and policy insurance amounts.
- Individual charge amounts and totals.
- Title commitment requirements — the curative report. This is the most sensitive material in a title file: prior mortgages and payoff figures, tax liens against named individuals, divorce decrees, and similar records. It is never persisted by us.
- Free-text notes on the order.
- Appointment event names, which we have observed embedding borrower surnames.
If our database were breached, what an attacker would obtain is order status, milestones, dates, business entity names, staff email addresses, and encrypted loan numbers. Not borrower identity, and not the liens-and-decrees material that turns a breach into consumer notification letters.
One consequence worth stating: because we don't hold borrower names or street addresses, they cannot be searched for in TitleBridge. Loan-number search is exact-match only. That's a deliberate trade.
"Never stored" is not the same as "never transmitted." Some of this information does pass through us in flight — rendered to an authorised viewer (section 6) or included in a delivery to a customer's own connected system at their direction (section 9). What we avoid is becoming a custodian of it at rest.
6. The live view of sensitive detail
Title staff sometimes genuinely need the sensitive detail — a support case, a curative question. Rather than storing it against that possibility, we fetch it on demand:
- An authorised user asks to view sensitive detail for one order.
- We check they are entitled to that order, then record an audit entry — who, which order, when. The audit entry never contains the content.
- We fetch the detail live from Qualia and return it directly to that person's browser.
- It renders in browser memory only, marked no-store. It is not written to our database, not cached, not placed in browser storage, and not logged.
These requests are rate-limited per user. Our logging pipeline is explicitly configured to exclude these responses, because an ordinary request logger or error handler is the most likely way sensitive content would otherwise reach disk.
7. Information we collect directly
Separately from title data, we collect the following as a controller:
| Context | What we collect |
|---|---|
| Demo request | First and last name, work email, phone number, company or organisation. |
| Contact form | Name, work email, company, subject category, and your message. |
| Portal accounts | Name, work email, role, and a password stored only as a bcrypt hash. We record last sign-in, and log account changes such as password resets and role changes. |
| Support | Your correspondence, plus anything you choose to attach. We ask for order numbers and event IDs rather than screenshots of borrower detail. |
| Web server logs | IP address, user agent, requested path, and timestamp, kept for security and troubleshooting. |
| Billing | Billing contact, entity name, and address. Card details go directly to our payment processor; we never receive or store them. |
Application logs identify records by internal IDs and order numbers only. We do not log borrower personal information.
8. How we use information
- To provide the service: reading order changes, maintaining the timeline, and delivering updates to the destinations a customer has approved.
- To operate the portal and authenticate the people using it.
- To monitor and alert on failures — failed deliveries, expired credentials, connections going down.
- To respond to demo requests, contact messages, and support enquiries.
- To invoice and collect payment.
- To secure our systems and investigate abuse.
- To comply with legal obligations and to establish or defend legal claims.
We do not sell personal information, we do not share it for cross-context behavioural advertising, and we do not use title order data to train machine learning models or for any purpose beyond delivering the service to the customer it belongs to.
9. Where data goes
From Qualia to us
Our connection to Qualia is read-only for order data. We receive change notifications and also poll periodically as a backstop so nothing is missed. The only write we ever make to Qualia is configuring our own webhook subscription, which an administrator initiates. We never create, edit, or delete a title file.
From us to Salesforce
Updates are delivered as a signed webhook to a receiving application in the customer's own Salesforce org. Three properties are relevant here:
- We hold no Salesforce credentials. We do not log into anyone's Salesforce org. We send a cryptographically signed message to an endpoint the customer controls, and their application decides what to write.
- The delivered payload does contain personal information — borrower names and emails, the property address, and open title requirements — because that is what makes the record useful on the receiving end. This is disclosure to the customer's own system, at their direction, under their agreement with us.
- We transmit it without retaining it. Each delivery is assembled in memory at send time from a live read, not replayed from storage, and the record we keep of what was sent is scrubbed of that detail — so the delivery log cannot leak it either.
A connection can be scoped to specific mortgage brokerages. A scoped connection receives only orders originated by those firms, so a broker's system never sees another broker's book.
Back from Salesforce to us
A connected application can report loan lifecycle events to us — for example, that a loan was withdrawn — authenticated with a per-connection key. We respond by emailing the title company so a person can act in Qualia. We never write that information into Qualia ourselves.
10. Service providers
We keep this list deliberately short, and the database is not on it — it runs on our own infrastructure and is not exposed to the public internet.
| Provider type | Purpose |
|---|---|
| Hosting | The virtual servers running our services and database. |
| Email delivery | Operational alerts, reverse-channel notifications, and correspondence. |
| Payments | Invoicing and card processing, which happens entirely on the processor's systems. |
| Professional advisers | Lawyers, accountants, and auditors, where necessary and under confidentiality. |
Each is bound to process data only on our instructions. We'll also disclose information where required by law, court order, or valid legal process, or to protect our rights, safety, or property; and in connection with a merger or sale of assets, subject to this policy continuing to apply. A current list of subprocessors is available on request from privacy@titlebridgeapp.com.
11. GLBA and the Safeguards Rule
Title and settlement companies are financial institutions under the Gramm-Leach-Bliley Act, and the information in a title file is nonpublic personal information. As a service provider processing that information, we operate under the FTC Safeguards Rule and under the data protection terms in our customer agreements.
Our architecture is designed to reduce what we hold rather than to rely solely on controls around what we hold — but storing the loan number and acting as the live conduit for sensitive detail both keep us squarely within scope, and we treat ourselves accordingly. We enter into data processing agreements with customers, and can supply our security documentation for vendor review at security@titlebridgeapp.com.
12. Cookies
This marketing website sets no advertising cookies and no third-party analytics trackers. Web fonts are requested from Google Fonts, which means your browser contacts Google's font servers when a page loads.
The TitleBridge portal uses a single strictly-necessary session token to keep you signed in. It carries no tracking function and cannot be disabled without breaking authentication.
13. Retention and deletion
| Category | Retention |
|---|---|
| Captured raw payloads | 12 months by default, configurable per customer. Purging clears the payload while preserving the event record itself. |
| Order timeline | Retained for the life of the customer agreement. The capture log is append-only by design, so history is added to rather than rewritten. |
| Delivery records | 13 months, scrubbed of sensitive detail at the point of writing. |
| Audit records | Retained for the life of the agreement. These record who accessed what and when, never the content accessed. |
| Backups | Nightly, retained 14 days, then overwritten. |
| Demo / contact | 24 months from last contact, unless you become a customer or ask us to delete sooner. |
| Support threads | Duration of the agreement plus 24 months. |
| Billing records | As required by tax and accounting law, typically 7 years. |
Deleting a customer's data is a deliberate, guarded action: it requires an administrator, a two-step typed confirmation, and it leaves a permanent record that the deletion occurred even though the underlying data is gone. Backups age out on the schedule above rather than being individually edited, so a deletion becomes complete across all copies within 14 days.
14. Security
- Isolation enforced by the database. Each customer's data is separated by row-level security in enforcing mode, not only by application code. A query that forgot its filter still returns nothing across the boundary, and a request for another customer's order returns "not found" rather than confirming it exists.
- Encryption. TLS in transit. Connection credentials and the loan number are encrypted at rest with AES-256-GCM, with the search index under a separate key so that key alone cannot reveal values.
- Credentials are never displayed again. Signing secrets and API keys are shown once at creation and stored encrypted thereafter. Passwords are stored as bcrypt hashes and never in readable form.
- Role-based access. Ordinary users see summarised, filtered information. Viewing sensitive detail or decrypting a loan number is restricted and individually audited.
- Account protection. Portal sign-in uses a minimum twelve-character password policy, uniform failure responses that prevent account enumeration, and lockout after repeated failed attempts.
- Signed webhooks. Outbound deliveries are HMAC-signed so a receiver can verify they came from us; inbound calls require a per-connection key, are size- and rate-limited, and are moving to signature-required.
- Continuous monitoring. Automated checks alert on failed deliveries, expired credentials, suspicious access, and connections going quiet.
Two things we'd rather state than have you assume: multi-factor authentication on portal accounts is not yet available and is on our roadmap, and our database is reachable only from the host itself rather than from the internet. If you believe you've found a vulnerability, write to security@titlebridgeapp.com — we would much rather hear it from you.
15. Incident notification
If we become aware of a security incident affecting customer data, we will notify the affected customer without undue delay, with what we know, what we're doing, and what we recommend — recognising that as a service provider our customer carries the notification obligation to consumers and to regulators, and needs our facts quickly in order to meet it.
16. Your rights and choices
Depending on where you live, you may have the right to access, correct, delete, port, or restrict the processing of your personal information, to object to processing based on legitimate interests, and to withdraw consent. You may also opt out of the sale or sharing of personal information — which is straightforward here, because we do neither.
If you're a consumer on a title transaction
Contact the title company handling your file. They are the controller for that data and we act on their instructions; we generally cannot identify you within our systems, since we don't store borrower names. If you contact us directly, we'll refer you to them and help them respond.
If you're one of our business contacts
Email privacy@titlebridgeapp.com. We'll verify your identity and respond within the period applicable law requires — generally 30 days, and no more than 45 days for requests under California law. We won't discriminate against you for making a request.
If you're in the EEA or the UK and believe we've handled your information badly, you may complain to your local supervisory authority. We'd appreciate the chance to put it right first.
17. Where we operate
We operate in the United States, and the servers processing and storing data are located there. We do not routinely transfer personal information outside the United States. Where a transfer out of the EEA or the UK becomes necessary, we rely on the European Commission's Standard Contractual Clauses and the UK Addendum, with supplementary measures appropriate to the transfer.
18. Children
TitleBridge is a business product. It isn't directed at children, and we don't knowingly collect personal information from anyone under 16. If you believe a child has given us information, write to us and we'll delete it.
19. Changes to this policy
We update this policy when our practices change. The effective date at the top always reflects the current version. For material changes we'll give notice — by email to customer administrators, by a notice on this site, or both — before the change takes effect.
20. How to reach us
Privacy questions and requests: privacy@titlebridgeapp.com
Security reports and vendor review: security@titlebridgeapp.com
Everything else: the contact page
Postal mail can be sent to our registered office; write to us for the current address if you need it for a formal request.