How does BrokerDam handle SINs and sensitive documents?

A mortgage file is not an ordinary customer record. It carries identification, income, banking detail and, in most cases, a social insurance number. Three specific points are worth stating plainly.

SIN values are stored encrypted. Where a social insurance number is captured on a file, it is held in encrypted form rather than as plain readable text sitting in a database column. It is treated as a distinct category of data, not as one more field on a contact card.

Documents live in access controlled storage. Pay stubs, notices of assessment, bank statements and identification uploaded through the client portal are kept in storage with access controls, so a document belongs to the account and the file it was uploaded against. It is not a public link that anyone holding the URL can open, and it is not an attachment sitting in an email chain that has been forwarded three times.

The Velocity integration never transmits a SIN. This one is a property of the integration rather than a policy choice. The Velocity Deals Out API does not carry the SIN field, so there is no social insurance number in the data that moves from Velocity into BrokerDam. It is not filtered out after the fact. It was never in the payload.

Those three points are stated deliberately narrowly. There is a temptation for software companies to answer security questions with adjectives, and adjectives are not verifiable. What a broker can actually check is where the data sits, how a field is stored, and whether a given integration carries a given value.

Alongside those points, all customer data is hosted in Canada, in the ca central 1 region, which is covered in more detail on the data residency answer.

This is general information rather than legal advice. Your brokerage's own privacy obligations depend on your province, your lenders and your internal policies.