NYDFS wrote no AI rule, and made AI risk part of what the CEO certifies

The week

On October 16, 2024, the New York State Department of Financial Services, known as NYDFS or DFS, issued an industry letter titled “Cybersecurity Risks Arising from Artificial Intelligence and Strategies to Combat Related Risks.” DFS supervises a large share of the financial industry operating in New York, and the letter was addressed to the banks, insurers and other entities it regulates.

That population is wide. It includes state-chartered banks and trust companies, New York-licensed branches of foreign banks, licensed lenders and mortgage servicers, money transmitters and virtual currency businesses, and insurers and insurance producers licensed in the state. National banks and federal credit unions, chartered and supervised at the federal level, fall outside it. The letter went to the executives and information security staff of every entity inside it.

The concern behind it was concrete. A finance manager at a bank could get a video call from someone who looks and sounds exactly like the chief financial officer, asking for an urgent payment to be approved. By 2024, that scenario was no longer science fiction. Artificial intelligence had made it cheap to fake a voice or a face convincingly, and financial regulators were paying attention.

The letter itself cited a case from Hong Kong earlier in 2024. A worker there wired about $25 million after a video call on which the other participants had been deepfaked. The employee had seen and heard what looked like colleagues, and acted on it. No system was breached in the usual sense. The fraud worked by defeating a person’s judgment.

The guidance stated outright that it imposed no new requirements. Instead, it explained how the existing cybersecurity regulation, known by its legal citation 23 NYCRR Part 500 and usually just called Part 500, applies to AI. Part 500 is New York’s rulebook for how regulated financial firms must protect their systems and customer data: risk assessments, access controls, incident reporting and more.

The letter named four risks. The first was AI-enabled social engineering, including deepfakes. Social engineering means manipulating people, rather than hacking machines, into handing over access or money; a deepfake is AI-generated audio, video or images that convincingly imitate a real person. The second was AI-enhanced cyberattacks, in which attackers use AI to work faster and at greater scale. The third was the exposure created by large volumes of nonpublic information collected for AI, meaning the sensitive customer and business data that AI systems often need. The fourth was dependence on third-party AI providers, the outside companies that supply AI models and tools.

The letter then described how risk assessments, third-party oversight, access controls, training, monitoring and data management should account for these risks.

The specifics were sharper than the framing. The letter told firms to avoid authentication that relies on SMS text messages, voice or video, because those can be imitated, and to prefer digital certificates and physical security keys. Where firms use biometrics, it suggested liveness detection or texture analysis, techniques that check whether a live person is present rather than a recording or a mask. It also suggested combining biometric types, such as a fingerprint with behavioral signals like keystroke patterns.

On training, it asked that awareness programs cover deepfakes and AI-enhanced social engineering for all staff, senior executives and board members included. It suggested simulated voice and video impersonation exercises alongside the familiar phishing tests. On monitoring, it suggested that firms allowing staff to use AI tools watch for unusual query patterns that might signal an attempt to extract nonpublic information. It also suggested blocking queries that would expose such data to public AI products.

On data, it reminded firms to dispose of nonpublic information they no longer need, including data gathered for AI. It urged them to start now on the data and system inventories that Part 500 would require from November 2025, and to identify every system that uses or relies on AI. The letter was not all warning. It noted that AI can strengthen defense by automating review of logs and alerts, spotting anomalies and speeding response, and it encouraged firms to explore those uses.

It was not DFS’s first AI document that year. In July 2024 the Department had issued Insurance Circular Letter No. 7, on the use of AI systems and external consumer data in insurance underwriting and pricing. That letter dealt with fairness, governance and disclosure to consumers. The October letter dealt with security. An insurer now had two DFS documents describing expectations for the same technology from two different directions. At the federal level, the Treasury Department had published a report in March 2024 on managing AI-specific cybersecurity risks in the financial sector, so the themes were familiar.

Its timing mattered. The letter arrived midway through the phased implementation of the November 2023 amendments to Part 500, which were rolling in over several years. One of the biggest milestones still ahead was universal multi-factor authentication, due by November 2025.

The near-term calendar was crowded. Another tranche of the amended requirements took effect on November 1, 2024, two weeks after the letter. The next annual certification, due April 15, 2025, would cover calendar 2024. A firm reading the letter in October knew that the year it described was the year its executives would soon sign for.

Guidance that says it creates no new obligations is easy to file and forget. This letter deserved more attention because of how Part 500 works after its 2023 amendments.

Each April, a covered entity must certify compliance, or acknowledge noncompliance, in a document signed by its highest-ranking executive and its CISO, the chief information security officer. Two named people put their signatures to a statement that the institution meets the rule. The act is personal, not departmental.

The filing comes in two forms. A Certification of Material Compliance states that the entity materially complied with Part 500 during the prior calendar year. An Acknowledgment of Noncompliance admits that it did not. It identifies the sections the entity failed to meet, describes the nature of the gap and sets out a remediation timeline. The entity must keep the records supporting either filing for five years.

The second option matters for this letter. An institution that discovers in February that its AI vendors were never assessed has a choice. It can fix the gap and judge whether the year as a whole was still materially compliant, or it can acknowledge the gap openly. What it cannot do safely is certify compliance without having looked. Several DFS cybersecurity consent orders before 2024 cited certifications filed when the entity was not in fact compliant, which raises the stakes of a signature given on thin evidence.

By stating that AI risks fall inside existing Part 500 obligations, the letter put them inside that signature. An institution that has not addressed AI-driven risks in its risk assessment, access controls or vendor oversight has a certification problem as well as a policy gap. For a CEO, that changes the nature of the question. It is no longer “do we have an AI policy?” but “can I stand behind what I signed?”

The letter’s four risks form a clean frame. Two describe how attackers use AI against the institution: social engineering and enhanced attacks. Two describe exposure the institution creates through its own AI use: concentrated data and dependence on AI vendors. Every AI-related cyber risk an institution faces lies on one side of that line or the other. For each, what matters is the evidence the signers could show an examiner.

How guidance with no new rules shapes an examination

Regulators have several tools. Rules create binding obligations. Enforcement actions punish firms that break them. Guidance, like this letter, falls in between: it tells the industry how the regulator reads its existing rules. In practice, guidance shapes what examiners look for when they visit, and what they expect to see in a firm’s files.

A city’s building code may say that every building must have “adequate fire exits.” If the fire marshal later publishes a note explaining that, in her view, adequate includes exits that work during a power cut, no new law has been passed. But every building owner who signs an annual safety certificate now knows what “adequate” will be measured against.

DFS did the same. Part 500 already required firms to assess their cyber risks, control access, oversee vendors, train staff, monitor systems and manage data. The letter said, in effect, that AI changes those risks, so assessments and controls must reflect that. A firm that ignored the letter would still be judged against the same rule, by examiners who had read it.

Who the letter reaches, and how differently

Part 500 applies to “covered entities,” meaning any person operating under a license, registration, charter or similar authorization under New York’s Banking, Insurance or Financial Services Law. That covers state-chartered banks, licensed lenders, money transmitters, virtual currency businesses, insurers and licensed insurance producers. It does not cover national banks or federal savings associations, which answer to federal supervisors.

The rule is tiered. Class A companies are the largest. Broadly, they have at least $20 million in New York gross annual revenue, plus either more than 2,000 employees or more than $1 billion in global gross annual revenue, counting affiliates. They carry extra duties, including an independent audit of the cybersecurity program, privileged access management, endpoint detection and response, and centralized logging. Small entities that qualify for the limited exemption in section 500.19 are spared several requirements but keep core ones, including the risk assessment, multi-factor authentication, the third-party policy and the annual filing.

The letter therefore lands differently by institution. A Class A insurer reads the section on AI-enhanced attacks against an endpoint detection deployment and a central log platform it already runs. A ten-person licensed insurance agency, exempt from much of the rule, reads it against a short risk assessment and a contract with a managed service provider. A virtual currency business reads the social engineering section against a remote onboarding flow that may be its single largest exposure. Each signs the same kind of filing, but the evidence behind it should be proportionate to the firm.

Federally supervised institutions outside DFS’s reach faced the same risks under different paper. The federal banking agencies’ 2023 interagency guidance on third-party relationships and the FFIEC’s 2021 guidance on authentication and access already pointed in the same direction. A national bank would find little in the DFS letter that its own examiners could not also ask about. What was distinctive in New York was the personal certification.

The case against reading it this way

There is a fair objection to treating a guidance letter as a description of the certification file. Guidance is supposed to inform, not bind. If firms treat every “should consider” as a “must,” regulators acquire through letters what they could not adopt through notice and comment. Some recommendations were also expensive at scale, such as replacing SMS codes for millions of consumer logins.

The objection is right about the wording and wrong about the consequence. The letter separated what Part 500 requires, such as an annual risk assessment and multi-factor authentication for all authorized users by November 2025, from what DFS merely suggested, such as liveness detection for biometrics. A sound file respects that line. It shows the required items done. For each suggestion, it records whether the firm adopted it and, if not, why its alternative was adequate. A documented decision not to adopt a suggestion is defensible. Silence is harder to defend in front of an examiner whose agency wrote the suggestion.

The annual certification makes this sharper than it might otherwise be. A misstatement in a certification is a more serious matter than a gap in a policy manual. So the practical way to read the letter is as a description of what should be in the file behind the signature.

AI-enabled social engineering: evidence that a human is never the only authenticator

The letter treated deepfakes in audio, video and text as the most significant threat, for a simple reason. For generations, organizations have used human recognition as a security check. A teller knows a regular customer. A finance clerk recognizes the CFO’s voice. A help desk agent can tell when a caller sounds legitimate. AI weakens every one of those checks.

Any step that relies on recognizing a voice or face, or on a convincing message, is weakened. That covers callback verification to an executive whose voice can be cloned, video calls used to approve payments, and help desk resets granted to a plausible caller. Callback verification, where staff confirm a request by phoning the person back, was long considered best practice. It still helps, but it is not enough if the voice on the other end can be synthetic.

Three channels where impersonation pays

Deepfake fraud concentrates where a single human decision moves money or grants access. Three channels account for most of that exposure in a regulated financial firm.

The first is payments and changes to payment instructions. The Hong Kong case the letter cited fits this pattern: an employee wired about $25 million after a video call on which the other participants were fakes. Vendor bank-detail changes and urgent executive requests belong here too. The control is dual approval through separate channels, with the second approver reached at a number held in the firm’s own records, never one supplied in the request.

The second is account recovery. Help desks that reset passwords or re-enroll an authentication device on the strength of a phone call can hand an attacker a working account. Widely reported intrusions in 2023, including the attack on MGM Resorts, began with a call to a help desk, and AI voice tools make such calls more convincing. The stronger pattern requires the caller to prove possession of an enrolled device, or to be verified in person or by a manager who knows the employee, before any reset.

The third is customer onboarding and authentication. Firms that open accounts remotely rely on document checks and selfie matches. The letter warned that deepfakes can defeat biometric verification, and suggested liveness detection, texture analysis and combined modalities. For a money transmitter or virtual currency firm that onboards every customer online, this channel may matter more than the wire room.

What stronger authentication looks like

Authentication means proving you are who you say you are. Multi-factor authentication requires more than one kind of proof, usually something you know (a password) plus something you have (a phone or a device) or something you are (a fingerprint).

The letter encouraged authentication that resists AI impersonation, such as digital certificates and physical security keys, and cautioned against relying on SMS, voice or video alone. A digital certificate is a cryptographic credential installed on a device that proves the device belongs to a trusted user; a physical security key is a small device that must be present to log in. Neither can be faked by a convincing voice. Text messages, by contrast, can be intercepted or redirected, and voice or video can now be imitated.

Part 500’s multi-factor authentication requirement, expanding to all users by November 2025, provides the hook. The evidence an examiner would expect is an inventory of processes where a person is the authenticator, with the added factor documented for each: payment approvals, vendor bank-detail changes, privileged access requests and help desk resets. A process missing from that inventory is the likeliest place for a deepfake to succeed.

Take a regional bank whose wire transfer process is well protected with security keys. A vendor, though, can change its bank account details by emailing the accounts payable team, who confirm with a phone call to a number in the email. A fraudster with a cloned voice and a fake email can redirect a payment without touching the wire system at all. The inventory exercise is how the bank finds that gap before a criminal does.

Training that rehearses the specific attack

Part 500 already required at least annual security awareness training that includes social engineering. The letter asked that it cover AI-enabled attacks, for everyone from front-line staff to senior executives and board members. Executives belong on the list for two reasons. Their voices and faces are the ones fraudsters copy, and their urgent requests are the ones staff hesitate to question.

Rehearsal works better than a slideshow. The letter suggested simulated voice and video impersonation exercises alongside phishing tests. A treasury team that has received a fake “CFO” call in a drill, and been praised for hanging up and calling back, is likelier to do the same under real pressure. The evidence for the file is the exercise record: who was tested, what share followed the verification procedure, and what changed afterward.

The trade-off is friction. Every added check slows a legitimate urgent payment, and senior people are often the ones who object. A written rule that no verification step may be waived, whatever the requester’s seniority, protects the employee who enforces it. Without that rule, the control depends on a junior person’s willingness to challenge a senior one.

AI-enhanced attacks: evidence that fundamentals run faster

AI helps attackers find vulnerabilities, write exploit code and tailor lures faster and at greater scale. A vulnerability is a weakness in software that can be abused; an exploit is the code that abuses it; a lure is the bait, such as a phishing email, that tricks someone into clicking. For the most part AI does not create new classes of weakness. It makes existing attacks cheaper and quicker.

The defensive consequence is that existing controls, patching, vulnerability management, logging and monitoring, must run on shorter cycles. If attackers can turn a newly published software flaw into a working attack in days rather than weeks, a bank that patches monthly is exposed for longer than it used to be. The race is the same; the opponent is faster.

Here the evidence is metrics. Time to patch internet-facing systems, by severity. Frequency of vulnerability scanning. Time from alert to containment. If those numbers have not changed since attackers adopted AI tooling, the risk assessment should explain why. There may be a good reason, but the signers should know it.

The letter also acknowledged that institutions can use AI for detection and response, for example to sift alerts or spot unusual behavior. Doing so is welcome, but those tools then need the same access controls, change management and monitoring as any other system with privileged visibility. A security tool that can see everything is itself a high-value target.

Those tools also ingest logs, email and endpoint data, often in the vendor’s cloud. That makes the security vendor a third party with broad access to nonpublic information, which brings it into the vendor program discussed below.

Turning faster attacks into targets

A risk assessment that says “AI makes attacks faster” is useful only if it changes a target. A sensible approach ties patch windows to exposure and known exploitation, not to severity scores alone. Internet-facing systems with a flaw listed in CISA’s Known Exploited Vulnerabilities catalog warrant the shortest window. Internal systems with no known exploitation can wait longer. The assessment then records the targets, the actual performance and every exception.

End-of-life software deserves its own line. Systems that no longer receive vendor patches gain nothing from a faster cycle. Part 500 requires vulnerability management, and the file should show which unsupported systems remain, what compensating controls surround them and when they will be retired.

Detection matters as much as prevention. Class A companies must run endpoint detection and response and centralized logging with alerting. Smaller firms often buy the same capability from a managed detection provider. Either way the measure is the same: the time between the first suspicious event and a human decision to contain it, and whether that interval holds at night and on weekends.

The skeptic’s view of AI-accelerated attacks

In 2024 the public evidence that AI had transformed intrusion techniques was thinner than the commentary. Reported uses mostly improved phishing text, translation, research and scripting. Ransomware crews still got in mainly through stolen credentials, unpatched edge devices and social engineering. A skeptic could fairly argue that the letter’s second risk was more forecast than fact.

The argument holds anyway, because the controls it implies are right regardless. Shorter patch windows on edge devices, faster containment and better logging defend against the attacks that were already succeeding. If AI acceleration arrived slowly, the firm lost little by tightening early. If it arrived quickly, the firm was ready. That asymmetry is why the section belongs in the risk assessment even for a skeptic.

Data concentration: evidence that AI data stores are inside the perimeter

AI systems are hungry for data. Training, fine-tuning and retrieval often involve copying large volumes of nonpublic information, sometimes including biometric data. Training is how a model learns in the first place; fine-tuning adapts an existing model with an organization’s own examples; retrieval means fetching relevant documents at the moment a question is asked so the model can use them in its answer. Each can involve making new copies of sensitive information.

The resulting stores are attractive targets, and data science teams often build them quickly, outside normal controls. A team building a customer-service assistant might copy years of customer emails into a new database to test an idea, with the best intentions and no one in security aware it exists.

Part 500 already requires an asset inventory, access controls, data retention limits and secure disposal. The letter asked institutions to apply them to AI data. Evidence would start with AI datasets and vector stores listed in the asset inventory, each with a named owner. A vector store is a specialized database that holds documents in a form AI systems can search by meaning; in practice, it often contains the same sensitive content as the original files, organized differently.

Access lists should be reviewed on the same cycle as other sensitive systems. Retention rules should cover training copies and prompt logs, which often hold customer data that nobody meant to keep. A prompt log records what people typed into an AI tool, and employees routinely paste in account details, complaints or contract terms.

Biometric templates deserve particular care, because a stolen template cannot be reissued the way a password can. A biometric template is the stored mathematical representation of a fingerprint, face or voice. If a password leaks, the customer picks a new one. If a face template leaks, the customer still has the same face.

Retrieval systems and the permissions problem

One weakness deserves particular attention. Many internal assistants answer questions by retrieving documents from an index built from file shares, email or ticketing systems. If the index does not carry over the access rights of the source documents, any user of the assistant can retrieve content they could never open directly. An underwriting memo or a fraud investigation file becomes searchable by anyone with access to the tool.

Assistants built into productivity suites have the opposite problem. They respect existing permissions faithfully, which exposes how loose those permissions already were. Years of files shared with the whole company become easy to find. In both cases the access review for an AI system has to cover what it can retrieve as well as who can log in.

Monitoring what goes out

The letter suggested watching for unusual query patterns that might signal an attempt to extract nonpublic information, and blocking queries that would send such data to public AI products. The second suggestion is usually implemented through data loss prevention rules and web filtering. Firms typically allow an approved enterprise AI service, block or warn on consumer tools, and inspect pasted content for account numbers and similar identifiers.

Blocking has a cost. Staff who find the approved tool weaker than a consumer one may move the work to a personal phone, where the firm sees nothing. The more durable answer pairs blocking with a sanctioned tool good enough that people prefer it. The file should show both the controls and the approved alternative.

How the exposure differs by business

The data at stake differs sharply. A life or health insurer holds medical information gathered in underwriting and claims. A bank holds account and transaction histories. A virtual currency business holds identity documents and wallet data. Each carries different notification duties and different harm to customers if it leaks, so the same AI project carries different risk in each.

Disposal is the neglected control. Part 500 requires secure disposal of nonpublic information that is no longer needed, and the letter applied that explicitly to data held for AI. Training copies and test datasets tend to outlive the projects that created them. A retention rule written for the source system rarely follows the data into a data scientist’s workspace, so the file should show that someone checked.

Third-party dependence: evidence that AI vendors are in the vendor program

Most institutions use AI through vendors, from cloud model providers to software products with embedded AI features. Many firms are using more AI than they realize, because familiar products have added AI features in routine updates without much announcement.

Each brings data access and a dependency that may be hard to replace. The letter asked institutions to apply their third-party service provider policies to AI vendors, including due diligence, contractual protections and notice of cybersecurity events.

The questions are familiar but sharper: what data the vendor sees, whether it retains or trains on that data, where it is processed, and what happens to operations if the vendor fails or changes its model. The last is newer than it looks. AI vendors update their models frequently, and a change can alter how a tool behaves even when nothing in the bank’s own systems has changed.

The evidence gap is often contractual. Many AI services are used under click-through terms rather than negotiated agreements, which leaves the institution without notice rights or audit access. Click-through terms are the standard conditions accepted with a single click when signing up. A list of AI vendors with the contract type for each shows an examiner, and the signers, where that gap sits.

What to put in the contract

The letter was specific about contract terms. It suggested that firms consider representations and warranties from AI providers about the secure handling of nonpublic information. It also suggested using enhanced privacy and security options where a provider offers them. Many model providers sell enterprise tiers under which customer inputs are not used for training and retention is limited. Choosing that tier, and recording why, is evidence in itself.

Notice obligations need adapting. A standard clause requires notice of a cybersecurity event affecting the firm’s data. From an AI provider, a firm may also want notice of material model changes, of new subprocessors that will handle its data, and of changes to retention or training practices. Audit rights against a large model provider will rarely mean on-site inspection. More often they mean access to independent assurance reports, such as a SOC 2 Type II report, and a right to ask follow-up questions.

Fourth parties and concentration

Much AI reaches a firm indirectly. A claims platform, a customer relationship system or a call-center tool may send data to a model provider the firm never contracted with. That provider is a fourth party. The due diligence question for the direct vendor becomes which model providers it uses, what data it sends them, and on what terms.

By 2024 the market for leading models was concentrated in a handful of providers. Several of a firm’s vendors may depend on the same one, so an outage or a policy change there could affect many processes at once. A vendor inventory that records the underlying model provider for each AI feature makes that concentration visible, and feeds the business continuity plan.

Where negotiation is not realistic

A small insurer or licensed lender has little bargaining power with a global model provider. Insisting on bespoke terms may simply mean going without the tool. A credible file says so. It records the provider’s standard enterprise terms, the gaps against the firm’s policy, and the compensating controls, such as keeping nonpublic information out of the tool. It ends with a named executive’s acceptance of the residual risk. Part 500 requires a third-party policy. It does not require every contract to be negotiated, but it does require that someone accountable has decided.

One insurer’s certification file, risk by risk

Suppose a mid-sized insurer is preparing its April certification.

The chief information security officer starts with social engineering. Her team lists every process where a person is the authenticator. Most are covered: staff logins use security keys, and large payments need two approvers on separate devices. But the list turns up two gaps. The help desk resets passwords for callers who answer a few personal questions, and the claims team changes a policyholder’s payout account after a phone call. Both now get an added factor, and the change is recorded in the file.

Next, enhanced attacks. The team pulls a year of numbers: how long critical patches took on internet-facing systems, how often scans ran, how long it took to contain confirmed alerts. Patch times have barely moved. The risk assessment now says so, sets a shorter target and explains the plan to reach it.

Then data. A quick survey of business units finds a vector store built by the underwriting team for an internal assistant, holding thousands of policy documents with customer details, and a prompt log nobody had thought about. Both go into the asset inventory with named owners, an access review and a retention period.

Finally, vendors. The procurement team lists every supplier that provides or embeds AI. Two are on click-through terms and see customer data. Negotiated agreements with notice and audit rights are put in place before renewal.

The sequencing matters as much as the content. The insurer starts in the autumn, because the certification covers the whole prior year. A gap fixed in March shows remediation, but the year still contained the gap. The CISO’s team therefore runs the four reviews in the fourth quarter, closes what it can before December 31, and records the rest with dates.

One renewal falls in May, after the year has closed. Until then the insurer limits that vendor to data without customer identifiers. Senior management decides whether the remaining gap is material. If it is, the filing becomes an Acknowledgment of Noncompliance naming the section and the remediation date. The decision and its reasoning go into the file.

The effort is modest compared with a new program. Most of the work is inventory and documentation that existing teams already know how to do. The hardest part is usually organizational: getting data science, procurement and business units to report AI use they never thought of as a security matter.

When the chief executive and the CISO sign in April, the file behind their signatures covers all four risks, shows what was found, and shows what was done. The insurer needed no new AI program for any of it. Every step used controls Part 500 already demanded, pointed at a new kind of risk.

What directors should see before the signature

Board reporting closes the loop. The amended rule expects the board, or a committee, to have sufficient understanding of cyber risk to oversee it. Directors do not need to become technologists, but they do need enough grasp of the main risks to ask informed questions and judge the answers.

A short annual briefing on these four risks, with the metrics above, gives directors a basis for the oversight the rule expects and gives the signers a record that the board was informed. A sensible format is one page per risk: what it is, what the institution does about it, the key numbers and the open gaps.

The amended rule also requires the CISO to report in writing to the senior governing body at least annually on the cybersecurity program and material cyber risks. That report is the natural home for the four AI risks. Including them gives the board a record of being informed, and gives the signers evidence that oversight happened before the certification rather than being assembled afterwards.

Board minutes are part of the evidence. An examiner reviewing oversight will read whether directors asked questions and whether management followed up. A briefing that produced no discussion reads very differently from one that produced a request for a deeper review of help desk resets.

Overload is the opposite danger. Boards in 2024 were receiving AI briefings from strategy, compliance, legal and risk teams, often with overlapping content. Folding the cyber side of AI into the CISO’s existing report, instead of adding a separate AI paper, keeps the oversight record in one place and avoids conflicting numbers.

The four sections together describe a certification file. An institution that can produce it is in a stronger position than one with an AI policy that sits apart from its cybersecurity program.

Where certification files fall short

• Filing the letter as optional because it created no new rules, while the certification it bears on is anything but.
• Keeping AI governance separate from cybersecurity, so the AI policy and the Part 500 program never meet.
• Protecting the obvious payment channels while leaving help desk resets and vendor bank-detail changes to human judgment alone.
• Measuring nothing, so nobody can say whether patching and response have kept pace.
• Letting AI data grow in the shadows, with datasets, vector stores and prompt logs outside the asset inventory.
• Accepting click-through terms for vendors that see customer data.

What the signers should be able to show

1. If I signed our Part 500 certification today, what evidence would show that each of the four AI risks is addressed?
2. Where in our organization does a person approve something based on recognizing a voice, a face or a convincing message, and what second check backs each one up?
3. How long does it take us to patch our most critical internet-facing systems, and has that changed in the last year?
4. Which AI datasets, vector stores and prompt logs exist, who owns each, and are they in our asset inventory?
5. Which of our vendors provide or embed AI, what data do they see, and which are on click-through terms?

With hindsight

FinCEN, the Financial Crimes Enforcement Network within the US Treasury, issued its own alert on deepfake fraud schemes the following month, reinforcing the authentication point. Two regulators, one state and one federal, were now pointing at the same weakness: processes that trust a face, a voice or a convincing message.

FinCEN’s alert, issued on November 13, 2024, said the agency had seen an increase in suspicious activity reports describing suspected deepfake media. Most involved fraudulent identity documents used to get past identity verification. That pointed at a channel the DFS letter had touched on mainly through biometrics: remote onboarding. For money transmitters, virtual currency firms and online lenders, which open accounts at volume without meeting customers, it was the most exposed point.

Law enforcement reached the same conclusion. In December 2024 the FBI warned that criminals were using generative AI to clone voices to get into bank accounts, and to pose as executives in live video chats. Its advice to the public was the advice the DFS letter gave to firms: hang up and call back on a number found independently. In May 2025 the FBI warned of a campaign using AI-generated voice messages that impersonated senior US officials. By then, voice alone had stopped being credible evidence of identity in any security process.

The letter aged well because it did not depend on any particular technology. It described risks in terms of what attackers do and what institutions expose, and tied each to controls that already existed, which kept it durable as AI tools changed rapidly around it.

Some of its recommendations were easier to meet than others. Replacing SMS and voice with certificates or security keys was practical for employees and contractors. For consumer logins it was a long migration, and the letter framed it as a preference rather than a rule. Institutions that kept weaker customer factors needed a documented rationale and compensating controls, such as transaction monitoring, rather than a wholesale replacement.

NYDFS kept enforcing Part 500. In January 2025 it announced a $2 million settlement with PayPal after criminals used compromised credentials to reach customers’ unredacted tax forms. Among other failures, DFS found that PayPal had not required multi-factor authentication, a reminder that authentication gaps were an enforcement matter rather than a question of best practice. It also showed that the weaknesses regulators care about are often basic ones, whatever the technology involved.

The November 2025 deadline for universal multi-factor authentication arrived as scheduled. In October 2025 NYDFS issued a further industry letter on managing third-party service providers, which again added no rules but stressed that compliance cannot be delegated to a vendor. That message applies with particular force to AI, where so much capability arrives through outside providers.

The November 2025 date also brought the requirement to maintain an asset inventory of information systems, which the letter had urged firms to start early for AI. Firms that had followed that advice met the deadline with AI systems already listed. Others had to find them first.

Federal policy moved the other way. In January 2025 the new administration revoked the 2023 executive order on AI, and in July 2025 it published an AI Action Plan oriented toward adoption. With federal policy lighter, state regulators and existing rules remained the main source of supervisory expectations on AI risk in financial services. In regulated institutions, AI risk is managed through the same program, and certified with the same signatures, as every other cyber risk. The firms in the best position are the ones that folded AI into that program early, rather than treating it as a separate project.