The compliance block: identifiers and disclosures in one place, on every page

The compliance block on a mortgage website should be one object: company identifier, individual identifier where relevant, licensed states, the equal housing notice and whatever else your compliance team specifies, written in one place and published on every page. Build it that way and a licensing change is a single edit that goes live the same day. Build it any other way and you will spend the next three years finding pages that say something out of date.

This article is about the structure, the governance and the failure modes. It is not about the wording. The wording belongs to your compliance team, your counsel or your lender, and a website company that drafts disclosure language for a regulated business is a website company overstepping. What follows assumes they have told you what it must say, and is about making sure the site actually says it, everywhere, forever.

Why this is a structural problem, not a copy problem

Every mortgage website has the same block of small print, and almost every one of them has it in the wrong shape: pasted into a footer template, then pasted again into an originator page template, then again into a landing page built by someone in a hurry.

The moment there are three copies, the block has stopped being one statement and become three statements that happen to agree today. Licensing changes. A state is added. A company identifier changes after an acquisition. Compliance revises a sentence. Each of those is now a hunt rather than an edit, and the page that gets missed is the one nobody remembers exists.

The fix is unglamorous. Define the block once, as a component with named slots. Fill the slots from records rather than from typing. Place the component wherever compliance says it goes. Then a change is a change to the source, and every page updates because every page was always rendering the same thing.

What belongs in the block

Ask your compliance team; the list below is the shape, not the content.

Company identity. The legal entity name and the company identifier, whatever your lender or your own registration provides.

Individual identity. For a personal site or an originator profile, the individual’s identifier. The Nationwide Multistate Licensing System publishes consumer-facing records, and borrowers do check, which makes an easy-to-find identifier a trust signal as well as a requirement.

Licensed states. The list, maintained as data rather than prose, so it can be rendered as a sentence in one place and as a list on a profile page without being typed twice.

Equal housing notice. Text, mark, or both, as your compliance team specifies. Housing and Urban Development publishes guidance on fair housing that your team will be working from.

Advertising disclosures. Anything triggered by what the site publishes. If a rate appears anywhere, Regulation Z brings requirements with it, which is one of several reasons rates on a marketing site should live in exactly one component if they exist at all.

Anything your lender adds. Employer policies frequently specify a line, a placement or a logo. Treat these as slots in the same block rather than as a separate paste.

Building the block as a component

One source of truth

Somewhere in the site there should be a single file or record holding the values: entity name, company identifier, the states list, the notice text, any lender-required line. Nothing else on the site types those values.

The test is simple. Search the site’s source for the company identifier. It should appear once. If it appears eleven times, the site does not have a compliance block, it has eleven pieces of small print that currently match.

Slots, so one block serves several placements

The footer version, the profile version and the in-page notice version are usually not identical: a profile page carries the individual’s identifier and states, the footer carries the company’s. Build one component that accepts what it needs and renders accordingly, rather than three components that will drift.

Generated per person, never typed

On a branch or enterprise site with many originator profiles, the individual lines come from the same record that produces the profile: name, identifier, states, title. If the record is missing an identifier, the build should be unable to publish that profile, or should publish it with the lines clearly absent rather than quietly omitted.

That constraint sounds harsh and it is the single most useful governance rule on a multi-person mortgage site. The alternative is a new originator page going live on a Friday without an identifier because whoever created it did not know it was needed.

Placement is a setting, not a rebuild

Compliance may ask for the block in the footer, near an estimator, at the foot of a program page, or all three. Because it is one component with one source, adding a placement is adding a line to a template. Nobody has to copy the text and nobody can introduce a variant by accident.

Versioning: being able to say what it said

At some point someone will ask what the site said on a particular date. An acquisition, an audit, a complaint, a state review. The answer should not be “we think it said this”.

Keeping the block in version control gives you the history for free, and that is one of the practical arguments for a site whose content lives in files rather than only in a database behind an editor. Every change to the block is a dated, attributed record of what changed and who changed it.

Alongside that, keep a short human-readable log: date, what changed, who asked for it. Six lines a year. Your compliance team will be grateful the first time it matters, and it takes a minute to maintain.

The failure modes, and what they look like

The page nobody remembers

A campaign landing page built for something eighteen months ago, still live, still indexed, carrying a version of the block from before the last change. This is the most common one, and it is caused by pages that were built outside the site’s normal structure.

The defense is structural: if there is no way to publish a page without the shared layout, there is no way to publish a page without the block.

The image of a notice

An equal housing mark saved as an image with the text baked in. It cannot be updated without a designer, it cannot be read by a screen reader unless someone remembered alternative text, and it looks wrong when the visitor is using a dark color scheme. Where a mark is required, use one that adapts, and keep any wording as real text next to it.

The block that is unreadable

Small print rendered in light gray at eleven pixels. This fails two different tests at once: it is hard for a regulator to regard as prominent, and it fails the contrast expectations any reasonable accessibility review will apply. The block should be quiet, not invisible. Ordinary body size, ordinary contrast, ordinary link styling.

The copy that lives in the content editor

A site where the footer text is editable in a content editor by anyone with a login is a site where the footer text will eventually be edited by someone without the standing to change it. Where a system allows it, lock the block, or keep it in the layer only the build can change and let the editor manage the pages.

The state list that became prose

“Licensed in several states including” is not a list. When licensing changes, that sentence is the one that gets missed, because updating it means rewriting a sentence rather than adding an item. Keep the states as data and render the sentence from it.

Making the block work in both color schemes and on every screen

A compliance block is the part of a page most likely to break when the design does something clever, because it is the part nobody looks at during a redesign.

Color. If the site supports a dark scheme, the block has to be legible in both, which rules out any color typed as a fixed value into the block itself. Colors should come from the same design tokens the rest of the page uses, so the block follows the scheme automatically. The same applies to any required mark: a black mark on a dark background is invisible, and a white box behind it is an ugly admission that the design never considered it.

Size. Smaller than body copy is conventional and acceptable. Smaller than can be read on a phone without pinching is not. The practical floor is a size you can read at arm’s length on a phone you did not adjust.

Contrast. Measure it, in both schemes, on the actual rendered page rather than in a design file. Gray-on-gray small print is the single most common accessibility finding on a financial website and it is trivially avoidable.

Width. On a wide screen, an unconstrained block of small print becomes a very long line that nobody reads. Constrain the measure the same way you constrain body copy.

Print. Someone will print a page, usually a program page, usually to show somebody else. The block should survive it. A print stylesheet that keeps the block and drops the navigation costs an hour and occasionally saves an argument.

Profiles: the hardest case on a multi-person site

A branch with twenty originators has twenty profiles, each needing its own identifier and its own state list, and each created at a different time by a different person under time pressure. This is where compliance blocks fail in practice.

One record per person, and the page is generated from it. Name, title, identifier, states, photograph, programs, contact. The page is a rendering of the record. Nobody edits the page.

A missing identifier is a build failure, not a blank space. If the record has no identifier, the profile does not publish. This is the constraint that makes the whole system work, because it converts a matter of diligence into a matter of process.

Departures are as important as arrivals. An originator who has left should not have a live profile carrying their identifier next to your company name. Removing a profile should be one change to one record, and it should be part of whatever offboarding checklist the branch already runs.

The roster page and the profiles must agree. Generate the roster from the same records. A hand-maintained list of people will diverge from the set of live profiles within a quarter, and the divergence is usually somebody who has left.

What to do about shared or team pages

A team page that represents several licensed people is a page where the individual identifiers still belong, usually alongside each name rather than bundled at the foot. Your compliance team will have a view. The structural point is the same: the identifier comes from the person’s record, so a team page assembled from three records cannot be published with two identifiers.

Working with a compliance team without wasting their time

Compliance reviewers on mortgage marketing sites are usually reviewing something they did not ask for, in a format that is hard to review, under time pressure. A few habits make the relationship much better and make the block more likely to be right.

Send them the rendered page, not the design file. They need to see what a borrower sees, at the size they see it, in both color schemes if the site has them.

Show them every placement at once. Footer, profile, program page, estimator. Reviewing one placement and discovering a second later is how a second round happens.

Tell them what is a component and what is not. A reviewer who knows the block is one object will review it once. A reviewer who suspects it is pasted everywhere will ask to see every page, and they will be right to.

Give them a way to ask for a change that does not involve a meeting. Whatever your revision process is, make a wording change to the block the easiest thing in it. If asking for a comma costs them an email chain, they will batch up requests, and batches take longer to land.

Hold launch for their sign-off. Not as a formality. A site that went live before compliance saw the block is a site that will be changed under pressure in its first week, which is when mistakes get made.

Reviewing it

Put the block on a review rhythm and make it someone’s job.

Quarterly: compliance reads the rendered block on a desktop page, a phone page and an originator profile, and confirms it still matches what they specified. Three minutes.

On any licensing change: update the source, rebuild, and spot-check three pages of different types. Log it.

On any new page type: confirm the block renders. This is the moment new gaps are introduced.

Annually: read the whole thing as a borrower would, looking for anything that has become stale, ambiguous, or that refers to a product or entity that no longer exists.

Why this earns its place on a website checklist

None of this wins a borrower. It is entirely downside protection, and that is exactly why it gets postponed until something forces it.

The argument for doing it at build time rather than later is that it is nearly free at build time and expensive afterwards. Building the block as a component on day one costs an hour. Retrofitting it into a site with forty pages, three templates and a landing page nobody remembers costs a week and still misses something.

It also makes the rest of the site cheaper to run. A branch that can publish a new originator profile in ten minutes, with the identifier lines guaranteed correct because they came from the record, is a branch that will actually keep its profiles current. Governance that is easy gets followed. Governance that requires care gets skipped by the third person who has to do it in a hurry.

For the wider structure this sits inside, a branch website that ranks in its own city covers how profiles and location pages are generated, and the loan officer website checklist covers where the block fits among the other things a borrower expects to find.