SitusAMC turned a mid-tier mortgage vendor into a top-tier bank exposure

The week

Over the weekend of November 22, 2025, it became public that SitusAMC, a New York-based provider of services and technology to real estate lenders, servicers and investors, had been breached. Most people had never heard of it. Firms like it sit in the background of the mortgage and property finance business, doing the paperwork-heavy jobs that keep loans moving between the institutions that make, service and invest in them.

The company said it became aware of the incident on November 12, notified law enforcement and brought in outside experts, the forensic investigators who reconstruct what an intruder touched. It said corporate data relating to some clients’ relationships with it, such as accounting records and legal agreements, had been affected. Some data about clients’ customers might also be involved, with the scope still under investigation.

It also said no encrypting malware was used and its services remained operational. The detail matters. Many of the cyberattacks that make headlines are ransomware: criminals break in, scramble the victim’s files so they cannot be used, and demand payment for the key. Those attacks are loud, because systems stop working. A breach without encrypting malware makes no such noise. The business keeps running, but information may have been copied and carried away. From the outside, nothing looks broken.

Then came the names. Press reports said JPMorgan Chase, Citi and Morgan Stanley were among the institutions notified, and the FBI said it was working with affected organizations. Suddenly a firm that many bank executives would have struggled to place was connected to some of the biggest names in American finance.

For risk and procurement teams across the industry, that weekend raised an uncomfortable question: if a company like this could hold data for so many large banks, how many similar firms sat in their own vendor lists, ranked as low priority because the contract was small and the service was not essential to keeping the lights on?

Third-party breaches are familiar in banking. SitusAMC was instructive because of the kind of vendor involved. It is not a core processor or a cloud platform, and for many clients it is not a large line in the technology budget. Yet firms like it handle loan files, valuations, due diligence and servicing data for many institutions at once.

Three procurement decisions determined how exposed each client was: how the vendor was tiered, what data was sent to it, and what the contract said about the day it was breached. Each is a business decision as much as a technical one, and each can be made well or badly long before any attacker arrives.

How banks sort hundreds of outside firms

A modern bank is less a single company than a hub connected to hundreds or thousands of outside firms. Some run critical systems, such as the core banking system, the central ledger that records every account and transaction. Others provide cloud computing, payment processing, call centers, legal services, appraisals or data analysis. Each of those firms is a “third party,” and each relationship carries risk the bank cannot fully control.

Third-party risk management is the discipline of deciding how much to worry about each one, and what to do about it. Because no bank can examine every vendor in depth, programs sort vendors into tiers. Top-tier vendors get the full treatment: security questionnaires, document reviews, sometimes on-site visits, contract terms negotiated by specialists, and a named person inside the bank who owns the relationship. Lower tiers get lighter checks, often little more than a questionnaire at onboarding.

A landlord deciding which tenants to check most carefully faces the same choice: a small tenant storing fireworks deserves more attention than a large one storing furniture, whatever the rent.

In mortgage and real estate finance, the specialist vendors are many. There are diligence firms that review pools of loans before they are sold to investors, valuation firms that estimate what properties are worth, servicing support providers, and analytics firms. Each needs data to do its job, often detailed data about individual borrowers.

Tiering: why spend and criticality miss data-dense vendors

Third-party risk programs tier vendors to decide how much diligence each gets. Most tiering models weight contract value and operational criticality heavily. A core processor lands in the top tier because the bank cannot run without it. A specialist firm paid per loan or per engagement may land lower, even if it holds detailed borrower records.

The 2023 interagency guidance on third-party relationships from the Federal Reserve, FDIC and OCC expects risk management proportionate to the risk a relationship presents, and it names access to sensitive customer information as a factor. Many models give that factor a single checkbox. A better design scores it separately, using the volume and sensitivity of the records held.

Two tests help. First, ask for each vendor how many customers the bank would have to notify if everything sent to that vendor were published tomorrow. Second, ask whether a breach would stop operations. SitusAMC illustrates a vendor that scores low on the second test and high on the first. Under a criticality-led model, it gets light-touch review. Under a data-led model, it gets security assessments, evidence of access controls and logging, and a named relationship owner. Access controls decide who can open which files; logging records who actually did, so that after an incident investigators can tell what was touched.

There is also a sector-level effect. A shared vendor concentrates many institutions’ data in one place. Each bank sees one modest relationship. An attacker sees a single target holding data on borrowers from dozens of lenders. Tiering models built bank by bank do not capture that concentration, so banks should ask vendors directly how many financial institutions they serve and whether client data is segregated, meaning kept separate so that a compromise of one client’s area does not automatically expose another’s.

Tiering also has to move with the data. A vendor that started with a narrow valuation task can, two years later, be receiving full servicing files because a business line expanded the engagement. Few programs re-tier on that kind of change, because the contract value may barely shift. A practical trigger is any new data feed or new data category sent to an existing vendor. That requires the teams that set up file transfers to tell third-party risk when a new feed goes live. Some banks route every outbound file transfer through a managed gateway partly so that this signal is captured automatically.

Data: what you send is what you can lose

Mortgage and real estate finance runs on documents. Loan tapes, which are spreadsheets listing every loan in a pool with its key details; appraisals; title files; servicing records and legal agreements move between lenders, servicers, investors, diligence firms and valuation providers. Each transfer has a business reason. Over time, vendors accumulate far more than any one task needs, and keep it after the task ends.

Minimization at the point of transfer is the cheapest control available. Minimization means sending only what the job requires. A diligence review of a loan pool may need loan-level performance data but not full Social Security numbers. A valuation may need a property address but not the borrower’s income documents. Masking or tokenizing identifiers before transfer, and sending files through a managed channel rather than ad hoc email or shared folders, shrinks what a breach can expose.

Masking hides part of a value, such as showing only the last four digits of an account number. Tokenizing replaces a sensitive value with a stand-in code that means nothing to an outsider; the bank keeps the key that links the code back to the real customer. If a tokenized file is stolen, the thief gets a list of codes rather than names and identity numbers.

The obstacle is organizational rather than technical. The capital markets or servicing team sending a file is measured on closing the deal, not on the fields in the file. Data owners in the bank rarely see these transfers. A workable fix is a short data specification attached to each statement of work, approved by the data owner, with retention limits and a destruction certificate at the end of the engagement. Spot checks of a few vendors a year show whether the certificates mean anything.

Suppose a regional bank sells a pool of mortgages and hires a diligence firm to review them. The deal team, in a hurry, sends the full loan files, including scanned identity documents and pay stubs, because that is how the files are stored. The diligence firm needed perhaps a tenth of that information. The deal closes; nobody asks for the files back. Three years later the diligence firm is breached. The bank now owes notices to thousands of borrowers whose identity documents it never needed to send.

Contract: who learns, who pays and who tells customers

When a vendor is breached, the bank still owns its obligations to its customers. Customers chose the bank, not the vendor, and regulators and state laws look to the bank. Several contract terms carry real economic weight.

• Notice that does not depend on disruption. The federal bank incident notification rule that took effect in 2022 obliges bank service providers to notify banks of incidents that disrupt or degrade service for four or more hours. SitusAMC said its services kept running. Even where a vendor counts as a bank service provider under that rule, a data theft without an outage falls outside it. The contract must require prompt notice of suspected unauthorized access to client data on its own terms.
• Cooperation and information. The bank needs enough detail, quickly, to decide which customers are affected and under which state laws. The contract should require the vendor to identify affected records by client and to share the forensic findings relevant to the bank’s data.
• Who sends notices and who pays. Contracts should settle whether the vendor or the bank notifies customers, who approves the letter, and who bears notification, call center and credit monitoring costs. Vendor insurance should be large enough to make the promise credible.

These terms are negotiable at signing and very hard to add after an incident. For a data-dense vendor, procurement should treat them as standard rather than as concessions reserved for the largest relationships. Banks with dozens of similar vendors can use a standard data-protection addendum so that the terms do not depend on each business line’s negotiating effort.

Two banks, one breach, very different Mondays

To see how these decisions add up, take two banks that use the same mortgage services vendor. Both are mid-sized, both send loan files to the vendor for diligence work, and both learn on the same Saturday that the vendor has been breached.

At the first bank, the vendor sits in a low tier because the annual fee is modest. Nobody inside the bank owns the relationship day to day. The deal teams have been emailing full loan files for years, and some engagements ended long ago without any request to return or destroy the data. The contract requires notice only of incidents that disrupt service. On Monday morning, the chief risk officer asks a simple question: which of our customers are affected? Nobody can answer. The bank has to wait for the vendor’s investigation, and the vendor is busy with many clients at once. Weeks pass. The board asks for an update and gets a description of what is not known.

At the second bank, the vendor was moved to the top tier two years earlier, when a data score was added to the tiering model and the vendor’s volume of borrower records pushed it up. A relationship owner keeps a list of every file sent, through a managed transfer gateway, with dates. Identity numbers were tokenized before transfer for most engagements. Two old engagements ended with destruction certificates, and a spot check last year confirmed one of them. The contract requires notice of suspected unauthorized access within a set number of days, record-level identification of affected data by client, and vendor payment of notification costs.

On Monday morning, the second bank’s team already knows the maximum population at risk: the borrowers in the files it sent during engagements still active. It knows that most of those files contained tokens, not identity numbers. It can tell the board a worst case, a likely case and a plan. When the vendor’s findings arrive, it matches them against its own transfer records and finalizes its notice list quickly.

Nothing the second bank did was technically sophisticated. It made a handful of ordinary decisions, earlier, and wrote them down. The difference shows up in cost, in the number of customers who receive alarming letters, and in how confidently leadership can speak during a difficult few weeks.

Four places a vendor breach shows up

A vendor breach reaches the executive suite through cost, customers, regulators and the time it takes to know the facts.

Cost. Notification letters, call centers to answer worried customers, credit monitoring offers, outside lawyers and forensic support all cost money, and the bill scales with the number of customers affected. Every unnecessary record sent to a vendor is a potential line item in that bill.

Customers. A borrower who receives a letter saying their data was exposed rarely distinguishes between the bank and the bank’s vendor. The trust lost is the bank’s. The best a bank can do is respond quickly, clearly and accurately, which depends on knowing exactly what it sent.

Regulators. Bank supervisors expect institutions to manage third-party risk in proportion to the risk. After a breach, the natural question is whether the bank’s own program had identified the vendor as holding sensitive data, and what it had done about it.

Reputation and time. The slow, uncertain period after a vendor breach, when the bank does not yet know which customers are affected, is corrosive. Leadership cannot answer the board, the press or customers with confidence. Good preparation shortens that period.

A program built around data rather than spend

A strong program has a few recognizable features. Every vendor has a data score as well as a criticality score. The bank keeps an inventory of which customer data goes to which vendor, refreshed when new feeds start. Transfers go through a managed channel, with identifiers masked or tokenized where the task allows. Engagements end with data returned or destroyed, and someone checks. Contracts with data-dense vendors include notice, cooperation and cost terms as standard.

The weak programs are the mirror image:

• Tiering by spend, so that a firm paid modestly per loan never gets a serious security review.
• Letting engagements grow unnoticed, with new data feeds added and no one re-tiering the vendor.
• Sending whole files because that is easier than extracting the fields a task needs.
• Assuming the regulatory incident notification rule will tell you about a data theft, when it turns on service disruption.
• Leaving data with vendors after the work ends, with no destruction certificate and no follow-up.
• Treating each vendor as a separate relationship without asking how many other institutions’ data sits in the same place.

Where a bank’s most data-dense vendors hide

1. Which of our vendors would force us to notify the most customers if everything we sent them became public tomorrow, and are any of them in our lower tiers?
2. Do we know which customer data goes to which vendor, and who tells third-party risk when a new data feed starts?
3. Do our contracts require vendors to tell us about suspected data theft even when their services keep running?
4. If a vendor were breached tonight, how quickly could we work out which of our customers were affected, and in which states?

The answers do not need to be perfect. They need to be specific. A team that can name its five most data-dense vendors, and describe what it sends each of them, is in a very different position from one that has to go and find out.

With hindsight

The early descriptions of the breach focused on corporate records. Notification letters sent to individuals in 2026, filed with state attorneys general, showed a wider picture for some people: depending on the person, names, addresses, dates of birth, government identification numbers and financial account information. SitusAMC said it had determined that data was taken from specific systems in mid-November 2025, and that it was not aware of fraudulent use. Class action litigation followed, and a proposed $5.3 million class settlement was before the federal district court in Manhattan by mid-2026.

The gap between an initial “corporate data” framing and later individual notices is the useful part for buyers. Banks that knew exactly which files they had sent, and could match the vendor’s findings to their own records, could judge their customer obligations quickly. Those relying on the vendor’s assessment could wait months: the individual letters went out in the spring of 2026. Tiering by data, minimizing transfers and contracting for record-level cooperation are what shorten that wait.

That gap is normal rather than suspicious. Early in any breach investigation, a company knows the least it will ever know. Forensic teams have to work out which systems were accessed, what files were in them, and whose information those files contained. The first public statement reflects that early, partial picture. Leaders should expect the scope of a breach to change, and should build their plans around finding out for themselves rather than waiting to be told.

A vendor’s size on the invoice says little about its size as a risk. The firms worth worrying about are the ones that hold a lot of your customers’ information, especially if they hold the same kind of information for many of your competitors too. Those firms deserve the attention usually reserved for the vendors you cannot operate without, and the contracts that go with it.