On this page
Lender guideline updates arrive as bulletins, portal notices, and long PDF revisions. A processor who reads every page loses half a day, while a processor who ignores them discovers the change when a file is rejected. A short change log gives the team one place to see what changed, which files are affected, and what to do next. The log is not a copy of the guideline. It is a working index for the people who apply it.
Log the change, not the document
A bulletin may contain twelve revisions, but only three may affect the team's current file mix. Record each relevant revision as one row with the effective date, the product or program, the old rule, the new rule, and the action required. That structure lets a processor find the answer without opening the source document again. A row that mixes two decisions will be reopened the next time either rule changes.
Link to the original bulletin in every row. The log is a pointer, not a substitute for the controlling document, and the reviewer needs to verify the wording. Use the lender's own title and bulletin number so the link is easy to find later. If the lender updates the bulletin, add a new row rather than editing the old one.
Keep the rows short enough to scan. A row that runs to a page is a sign that the change should be split into separate items. One row per decision is easier to assign and easier to close. The mortgage operations support lead can review the log weekly and remove rows that no longer affect active work.
Date the effective window
Every row needs two dates: when the lender published the change and when it takes effect. Some bulletins allow a grace period, while others apply to files received after a specific date. A processor who applies the new rule too early can create a different kind of error. The effective window prevents that mistake.
Add the date the team briefed the change and the date the first affected file was checked. Those dates show whether the log is moving from notice to practice. A log full of published changes with no briefing date is really an archive. The team needs to see the handoff from reading to doing.
When a change applies only to certain files, write the condition in plain language. A rule that affects cash-out refinances above a threshold is not the same as a rule that affects all refinances. The condition should be specific enough that a processor can decide whether a file is in scope without calling a manager. Name the product and the file stage in that condition so the scope is unambiguous.
Assign one owner per change
Each row needs an owner who is responsible for confirming the change and updating the affected checklist. The owner is not necessarily the person who found the bulletin. It is the person who can decide how the team will apply the rule and who will answer questions about it. That separation keeps the log from becoming a list of names with no decisions attached.
Give the owner a short deadline based on the effective date. A change that takes effect in two weeks needs a briefing before then, not on the morning it applies. If the owner cannot complete the review in time, the row should show the delay and the interim instruction. Silence is not an interim instruction.
Record the owner's confirmation in the row. A checked box without a name and a date cannot be audited later. If the change requires a system update, add a second owner for the system work. The separation makes it clear when the guideline is ready and when the tooling is ready.
Translate the rule into a file action
Processors need the action, not a paraphrase of the policy. Add a column that states what to do differently on the next file. For example, the action might be to request an additional income document or to change the condition label in the system. A clear action reduces the chance that two processors interpret the same rule differently.
Test the action on one file before the team adopts it. Pick a file that is in scope but not yet at the affected stage. Walk through the new step with the owner and note where the existing checklist fails. That test often reveals a missing field or an unclear instruction that the bulletin did not address.
Update the checklist and the training note in the same pass. A change log that points to an outdated checklist creates a contradiction the processor has to resolve alone. The Fannie Mae Selling Guide and the Freddie Mac Single-Family Seller/Servicer Guide are common sources of these updates, and both are easier to use when the team has already mapped the affected section. When the guide updates a section the team does not use, skip it and note why in the row.
Brief the change in five minutes
A briefing should take five minutes and cover three things: what changed, which files are affected, and what the processor should do today. Use one example from the team's own pipeline when possible. An example makes the rule concrete and gives the processor a pattern to match. A short agenda keeps the meeting focused and makes the missed items obvious.
Keep the briefing to the people who touch the affected work. Copying the whole company creates noise and reduces attention. Record the briefing date and the names of the attendees in the log. If someone missed it, the owner should provide a short catch-up rather than repeating the meeting.
Ask one question at the end: what part of this change is still unclear? The answers show whether the action is usable. If several people share the same confusion, the row needs a better example or the checklist needs a new step. A briefing that ends with no questions may mean the team did not understand enough to ask.
Audit adoption on live files
Choose two or three files after the effective date and check whether the new action appears in the record. Look for the document, the note, or the field that the change requires. If the action is missing, ask whether the processor knew about the change and whether the checklist supported it. The answer separates a communication problem from a compliance problem.
Record the audit result in the log next to the row. A row can be closed only when the action has been seen on a live file and the owner has confirmed the checklist update. That standard keeps the log honest. A change that was briefed but never adopted is still open work.
Review the log monthly for rows that are stale, duplicated, or no longer relevant. Merge rows that describe the same rule, and archive rows for retired programs. A short log that the team trusts is more valuable than a complete archive that nobody reads. The goal is a processor who can find the answer in under a minute and apply it with confidence.