A business development manager is the lender's relationship contact for a broker's overall business with that institution — distinct from the underwriter, whose job is assessing the specific facts of an individual file. A BDM helps with product knowledge, policy questions, occasional escalations, and generally keeping a broker informed about what's changing at that lender. Confusing the two roles — treating a BDM as someone who can simply approve a file, or treating an underwriter as the person to build a long-term relationship with — misunderstands what each is actually for.
A BDM who has seen a broker submit clean, honestly framed, well-documented files over time extends a kind of earned trust that a first-time submitter doesn't have: submission notes get read with more benefit of the doubt, genuine exceptions get escalated to the right underwriter faster, and upcoming policy or rate changes sometimes get flagged to trusted brokers before they're broadly public. None of this is favoritism in the sense of bending rules — it's the ordinary result of a lender learning, file by file, that a particular broker's work can be relied on.
The relationship this module describes is easy to damage and hard to rebuild. Using a BDM to push past a legitimate underwriting question, rather than actually answering it, teaches the BDM that this broker's escalations aren't reliable. Sending an unclear or incomplete file just to see what a lender will accept wastes the BDM's credibility along with the broker's own. And submitting a file that misrepresents the borrower — the exact failure Module 03 is built to prevent — doesn't just risk that one file; it damages every future submission's presumption of good faith with that lender.
Responding promptly to a BDM's own requests, giving advance notice of an unusually large volume of files so they can plan for it, and offering honest feedback in both directions — what's working well, what's genuinely slowing files down on the lender's side — all build the relationship in ordinary, unglamorous ways. None of these require a single dramatic gesture; the relationship is built the same way trust with an underwriter is built, through a consistent pattern over many files rather than any one interaction.
When a file has a real, well-documented exception to a lender's standard guideline — the kind that's honestly framed exactly as Module 03 describes, not spun or hidden — a BDM is often the right path to get that exception in front of the underwriter with useful context attached, rather than having it disappear into a generic queue. This only works because of the history behind it: a BDM advocating for an exception on behalf of a broker they trust is spending real credibility on that broker's behalf, and that credibility only exists because of a track record of files that didn't need it spent unnecessarily.
A broker has a file where the underwriter has raised a legitimate, unresolved question about income documentation. The broker considers asking the BDM to intervene to get the file approved without answering it. Is this a good use of the BDM relationship?
A BDM relationship is built on trustworthy escalations of genuine exceptions, not on getting past questions that haven't actually been answered — using it that way spends the relationship's credibility on exactly the kind of request that erodes it. Relationship strength or file size don't change the substance of the question here: an unresolved, legitimate underwriting concern needs a real answer, and the right move is providing one, not routing around it.
Lender policies change without notice. Confirm current guidelines directly with the lender or insurer before relying on them for a live file.
The intro and first module are free to read. Add your name and email once and the rest of this course opens — along with every other course on the site. No card, no trial.
Already unlocked on another device?
