A look at how we connect a lender’s own domain to the POS experience, and why the name in the address bar affects whether a borrower finishes an application.

In digital mortgage, a borrower decides whether to trust an experience before reading a word of it. An email arrives, a link gets clicked, an application loads, and somewhere in those few seconds the borrower has glanced at the address bar and formed an opinion about whether this is the institution they have been talking to.

Branding shapes that opinion, and so does the domain serving the experience, which is the part the industry has been slower to deal with. Lender-branded experiences are often served from provider-owned or shared domain patterns. The application is legitimate, and the lender relationship is legitimate, and the borrower still hesitates, because the name in the address bar is not the name on the letterhead. Browsers, email security tools, and reputation services read those patterns too, and they are built to be suspicious of a subdomain carrying one brand while resolving somewhere else.

When Branding and Domain Identity Do Not Match

Mortgage lending runs on trust that has to be earned early. Borrowers hand over tax returns, bank statements, income documentation, and personally identifiable information, and they do it at a moment when consumer awareness of phishing and spoofed sites is higher than it has ever been.

A lender-branded experience operating under an unfamiliar domain raises the questions any of us would ask:

• • • Is this really my lender?
    • Is this link safe?
    • Should I upload my financial documents here?

Every one of those questions is a pause. Pauses at the front of an application turn into abandonment.

White Labeling Usually Stops at the Interface

Historically, white labeling has meant visual customization. Swap the logo, apply the lender’s colors, update the messaging, and the experience looks like the lender’s own. That work is worth doing, and it covers the surface, while the infrastructure underneath still points at a provider-owned or shared domain.

We wanted to take it past the interface, so instead of branding what the borrower looks at, we aligned the underlying digital identity with the lender’s brand. Lenders can run their own branded domain while we carry the security, scale, and reliability of the cloud infrastructure behind it. Borrowers see their lender’s brand and a URL that reads as an extension of the institution they already do business with, and the lender keeps brand authority while we carry the infrastructure work.

What We Built

Our custom domain implementation is a repeatable framework for connecting a client-specific domain to AWS-hosted infrastructure. We establish the managed DNS path, handle certificate validation, configure secure content delivery, and hand the lender the records they need to delegate the branded subdomain.

Responsibility splits cleanly:

• • • The lender owns the brand and the parent domain.
    • We manage the technology path serving the POS experience.
    • Borrowers reach a branded, secure endpoint that lines up with the lender relationship they already have.

White labeling becomes an operational model rather than a design setting.

Can a Lender use its own domain for the Borrower and Seller experience? 

Yes. The setup runs in four steps, and only one of them sits with the lender. 

1. 1. 1. We create a public hosted zone. A dedicated Route 53 hosted zone is set up for the lender’s chosen fully qualified domain name, for example a seller portal subdomain on the lender’s own corporate domain. 
      2. We generate and configure the certificate. AWS Certificate Manager issues the SSL/TLS certificate for that name and we configure it in CloudFront. It renews automatically with no ongoing dependency on the lender. 
      3. We hand over the name server records. The four NS records from the hosted zone go to the lender’s team. 
      4. The lender adds one delegation. The lender enters the subdomain and those NS records in its own DNS. The parent domain stays entirely under the lender’s control. 

From there the branded endpoint resolves through a dedicated CloudFront distribution rather than a shared one, behind the same security controls and serving the same content as any other Empower deployment. 

What Sits Behind the Endpoint

Four AWS-native components do the work.

• • • Route 53 hosted zones: A dedicated hosted zone gives each lender-branded endpoint its own DNS foundation and routes it into the right managed environment, while the lender keeps ownership of its broader domain.
    • AWS Certificate Manager: Managed SSL/TLS certificates keep borrowers on trusted, encrypted connections, and they renew on their own, so certificate maintenance never lands on the lender’s operations team.
    • Dedicated CloudFront delivery: Each client gets a dedicated distribution rather than sharing a multi-tenant one. That is what makes the client-specific endpoint possible, and it keeps delivery fast and resilient under load.
    • DNS delegation: The lender delegates a single subdomain and nothing more. Control of the parent domain never leaves the lender.

What the Borrower Sees

Borrowers never see Route 53, ACM, or CloudFront, and they should not have to. What reaches them is their lender’s brand, on their lender’s domain, over a secure connection, inside the POS experience they were sent to. Nothing about it asks them to wonder where they are, so they can get on with the part of the process that needs their attention.

What the Lender Gets

The benefit runs past branding. A custom domain lines the lender’s identity up with the experience borrowers use every day, which helps lenders:

• • • Strengthen borrower confidence at the first click.
    • Support the security posture they already market to their members and customers.
    • Remove the confusion an unfamiliar URL creates.
    • Extend the same framework to other branded digital experiences as they add them.

The lender’s brand carries through the whole borrower journey rather than picking up again after the login screen.

Why We Are Building It This Way

Our POS is built into Empower on the same data model as the rest of the loan, so what a borrower enters at application flows straight through processing and underwriting without rekeying or reconciliation. A POS built that way should not announce itself as a separate product the moment a borrower looks at the address bar. Custom domain architecture closes the last gap between how the experience works and how it presents itself.

Mortgage technology is moving quickly, and most of the attention goes to what is visible: intelligence inside the workflow, the shift from doing to reviewing, the pace of what we ship. Established, evolved, AI-forward is how we describe where we are, and a fair amount of the evolved part turns up in places nobody puts on a roadmap slide, like a borrower who never thinks twice about the link they clicked.

If you are running our POS today, or evaluating it, ask your Dark Matter account team about setting up a custom domain for your branded endpoint. The build runs on our side and the lender’s part is a single DNS entry.

Want to learn more about our POS?
Click here to set up some time to talk with one of our experts today.