Building a compliant VOW

A Virtual Office Website is the mechanism that lets a Canadian agent show sold prices and other restricted data on their own site — legally, to registered visitors, under board rules. We have now built that mechanism into a platform, and the experience changed how we think about compliance software. The rules read like paperwork. Implementing them is real engineering, and every corner you could cut is a corner someone eventually audits. Here is what building it actually involved. (If VOW is new to you, start with what a VOW is.)

Identity is the product

Everything in a VOW hangs off one idea: restricted data is shown to a known person who accepted terms, not to the anonymous public. So registration is not a growth hack bolted onto the listings — it is the legal load-bearing wall. That shaped real decisions: visitor accounts are scoped per tenant site, the terms-of-use acceptance is recorded with a timestamp as click-wrap evidence, and the gate between an anonymous session and a signed-in one is checked server-side on every restricted surface. The distinction between what is public and what is gated — IDX versus VOW — has to be enforced at the data layer, because template code will eventually make a mistake.

Passwords with an expiry date

Board rules cap how long a VOW password may live: 90 days on TRREB, 30 days under the Vancouver-area tri-board rulebook. That means a compliant platform needs machinery most websites never build — a sweep that knows each tenant’s boards, derives the strictest applicable window, expires credentials on schedule, and walks the visitor through re-verification without losing their saved searches. When one site serves more than one board, the shortest window wins. It is precisely the kind of requirement that is trivial to state and easy to get subtly wrong, which is why we pinned it with tests instead of trusting ourselves to remember.

The blur is pre-meditated

Sold listings shown to anonymous visitors get a blurred photo treatment rather than sharp imagery — the compliant tease that invites registration. Our rule is that the blur is generated ahead of time, in the image pipeline, as its own stored derivative. There is no code path where a sharp sold photo is fetched and blurred on the fly, because any such path can fail open and serve the original. The reasoning behind blurred sold photos is a rules story; the implementation lesson is broader: make the compliant artifact the only artifact the page can reach.

The log that cannot be edited

VOW rules require records of consumer access, and a record you can quietly rewrite is not a record. Our VOW access log is append-only — the database itself blocks updates to it — and retained well past the minimums our terms disclose. This is the part of compliance nobody sees, and it is also the part that turns an awkward question from a board into a five-minute answer instead of an incident.

Fail closed, always

The design principle underneath all of it: when anything is uncertain — a session that will not verify, a board grant that will not resolve, an image derivative that is missing — the system serves less, never more. A visitor seeing a registration prompt they did not strictly need is a minor annoyance. Restricted data reaching an anonymous visitor is a licence problem. We built the TRREB implementation first and the Vancouver tri-board rulebook into the same machinery as our BC build progresses, and the full checklist we built against is written up in VOW compliance requirements. If you are evaluating any VOW vendor, ask them where their system fails open. If the answer is a pause, keep looking.