The software stack underneath a residential real estate transaction is invisible to almost everyone involved in the transaction. The buyer fills out forms in a portal, the agent uses a CRM that syncs to a Multiple Listing Service, the loan officer drives an origination platform that orchestrates a dozen integrations to credit bureaus and AVM vendors, and the title company runs an escrow accounting system that ultimately produces the wire instructions that move the buyer's down payment. Each of those systems is built on third-party components, integrates with third-party APIs, and is operated by a vendor whose security maturity varies dramatically across the industry. The buyer signs the closing disclosure assuming the whole pipeline is engineered like a bank, and it almost never is.
The downstream consequence of weakness anywhere in that pipeline is wire fraud, which the FBI's Internet Crime Complaint Center continues to rank among the highest-loss categories of business email compromise. The losses are not abstract; they fall on individual home buyers who lose their entire down payment and on small title agencies whose errors-and-omissions coverage is not sized for the volume of attacks the industry has been absorbing. The vector is almost always a compromise that started somewhere upstream in the software supply chain and ended in a fraudulent email or a manipulated portal screen at the moment of wiring.
What does the PropTech stack look like end to end?
On the brokerage side, the dominant systems are MLS platforms operated regionally by entities like Bright MLS, CRMLS, and Stellar MLS, which expose data to brokers through the RESO Web API standard and through proprietary integrations. Brokers consume that data with CRMs from kvCORE, Lone Wolf, Follow Up Boss, and a long tail of smaller vendors, and they layer on transaction management platforms like dotloop and SkySlope that handle document workflow. Every CRM that touches MLS data has implicitly accepted a software supply chain that includes the MLS's own platform vendors, the RESO middleware that translates between systems, and the dozens of integrations the broker has clicked Allow on.
On the financing side, loan origination systems from Encompass, Blend, and a handful of newer entrants integrate with credit bureaus, fraud-screening providers like LexisNexis Risk Solutions, automated valuation models from CoreLogic and Black Knight, and disclosure delivery vendors that produce the regulator-mandated forms. On the closing side, title production systems like ResWare and Qualia connect to underwriter portals, county recording systems, and the escrow accounting systems that actually move money. The number of distinct vendors whose software touches a single transaction routinely exceeds twenty, and each of those vendors has its own dependency tree that the lender and the title agent have no visibility into.
How does a software supply chain weakness become wire fraud?
The classic pattern starts with a credential compromise at a vendor in the chain, often a small brokerage or title agency whose tenant of a SaaS platform was breached. The attacker reads transaction context out of the SaaS account, learns the names of the parties, the closing date, and the wire amount, and crafts a fraudulent email that is indistinguishable from a legitimate one because it is based on real transaction data. The buyer receives wire instructions that look authentic, follows them, and the funds are gone before the bank's hold period expires.
The supply chain dimension is what most industry discussion misses. The credentials that were stolen at the small agency were often stolen because the SaaS platform shipped a vulnerable dependency that the platform's vendor never patched, or because a third-party integration the agency had enabled was the actual breach vector. The agency was a victim, but the upstream software vendor's hygiene was the proximate cause. The regulatory framework around wire fraud has not caught up to that reality, which means the small agency carries the liability for a failure several layers upstream in the software stack.
What do state regulators and ALTA expect in 2026?
The American Land Title Association's ALTA Best Practices framework has had an information security pillar since 2013, and the 2026 update materially expanded the supply chain expectations after a sequence of high-profile escrow account breaches. ALTA now expects title agencies to maintain a vendor inventory, to evaluate critical vendors on a documented cadence, and to have an incident response plan that addresses vendor-originated breaches specifically. The wording is permissive, but underwriters are using it as a contractual hammer; failure to demonstrate Best Practices compliance is increasingly a reason for an underwriter to suspend an agency's appointment.
State regulators have moved at different speeds. The New York Department of Financial Services Cybersecurity Regulation, 23 NYCRR 500, applies to title insurance entities and explicitly addresses third-party service provider risk. California's CCPA and the CPRA layered on top of it impose service provider obligations that title companies have to push down into their vendor contracts. The CFPB has taken interest in lender vendor management, and HUD has pushed FHA-approved lenders toward more rigorous oversight of their technology service providers. The cumulative effect is that a residential lender or title company in 2026 cannot defensibly operate without a real third-party risk program, and that program has to address software supply chain risk and not just the easier categories of physical and personnel security.
What about MLS integrations and the RESO Web API specifically?
The RESO Web API is a genuine improvement over the legacy RETS protocol, but it has introduced its own supply chain dynamics. The API specification is open, the conformance test suite is run by RESO, and individual MLS organizations are responsible for their own implementations. That means every MLS in the country is running a slightly different stack with a slightly different patch level and a slightly different set of integration partners. A vulnerability in a popular RESO middleware library can propagate to hundreds of MLS deployments before anyone outside the maintainer's immediate audience notices.
The brokerages consuming the API have even less visibility into what is happening upstream. The IDX feed that powers a broker's public website is typically delivered through a third party that aggregates data from the MLS, normalizes it, and serves it to the broker's chosen CRM or website provider. That aggregation step is another supply chain layer, with its own SBOM concerns, that almost no broker can articulate. The right approach is to demand transparency from MLS, IDX vendor, and CRM in sequence, and to treat the aggregate as one risk that needs to be measured rather than three separate vendor questionnaires.
How Safeguard Helps
Safeguard models the PropTech vendor surface as a connected graph so that risk from an MLS implementation flows through to the brokerages and lenders that consume its data, with TPRM scoring tuned to the specific platforms that dominate real estate technology. Griffin AI monitors the SBOMs and disclosure feeds for vendors like Encompass, Qualia, ResWare, kvCORE, dotloop, and the RESO middleware ecosystem, and alerts when a component in any of those stacks crosses a threshold that should trigger a vendor conversation. Policy gates can require minimum attestation and SOC 2 status for any system that participates in producing wire instructions, blocking integrations with vendors whose security posture has materially regressed. The audit trail and continuous evidence Safeguard produces is the kind of artifact that ALTA Best Practices and NYDFS examinations now expect, and it carries the same value when a buyer's counsel asks who exactly is responsible for the security of the money about to be wired.