Vermont Legislature SmartTranscripts:

[Michael Marcotte (Chair)]: Good afternoon, everyone. This is the Vermont House Committee on Commerce and Economic Development. It is Wednesday, March 11, twenty '26, 02:50 in the afternoon. So we're here to continue discussions on H-two 11, which is we've got a broker bill. We have our alleged counsel with us, Rick Sable. Rick? Good afternoon. Good afternoon.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Rick Sable with the Office of Police Voting Council. With a few changes to H2 level, I want to run value for all. Most of these are enforcement related, including up the, I mentioned last time, in chapter 62, protecting their personal information. Includes the data brokers, it includes the kids code, it includes other personal information, security breach notice, student proxy. It's been amended over the years and it's kind of messy in my opinion and I keep finding things I want to replace, so I want to show you some suggestions and you can tell me what you want to do with them. First, before we get there, we are draft 6.2. Think this is let me make sure you all have 6.2 on the website? Yeah. Jonathan? Okay. I think I didn't update this current one I'm looking at the number at the top. Okay, on page eight, does 6.2 have the AI definition your on 6.2 on the website? It does, okay. The new AI definition? I see January.

[Monique Priestley (Clerk)]: I'm just trying to open it.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: So there's been in the last several hours, there's a house bill in the healthcare committee that's dealing with AI and we're trying to, this committee is aware we're trying to ensure the same definition is used in our statutes.

[Monique Priestley (Clerk)]: It's not updated So one,

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: what I'm going to do is change this, sorry about that, it's been a crazy day, crossover week, this is 6.3. Jonathan, I'm going to email you this and you can post it. Okay, so for now you can see the screen what I've done here. This is the definition that I think is this in CSL where it recently

[Monique Priestley (Clerk)]: Yeah. So basically, like this so between our update on the executive order on AI and then chair Marcotte asked us to work with different groups like Transparency Coalition around like standard definitions that every state was using. And then the speaker's office asked NCSL for a definition of all of the different like AI, Gen AI, artificial intelligence systems, blah, blah, blah, blah, that all of the different states are using. And so health, this change is coming because healthcare is also working on a bill that incorporates Gen AI and artificial intelligence. So we're trying to make it so that we're standardizing definitions both in our bill, their bill, matching it to emerging definitions that are happening across the country and working from what California has in their latest AI bills, so that we're all consistent. It's a very, very, very minor change for our bill. It's more substantive change for the healthcare bill.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Yeah, so in this bill, the only time GenAI system is used is when data purpose or registering and they have to inform the state whether or not they sell super data to a AI system. So that's how that definition is used. So again, not critical for this bill. However, the health care bill, which at least relates to cat bots, is much more about AI than this bill is. When we get to perhaps data privacy or another AI bill that gets there, then we'll have a bigger conversation, but again the point is to ensure we have one kind of unified definition of AI, which is what this

[Unknown committee member]: is. So

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: moving on to the next change. On the definition of publicly available information on page 11 of draft 6.3, which hopefully Jonathan will get here soon, adding the phrase about a consumer. So publicly available information does not include all these different banks. The addition is an inference by the consumer. There is a question as to whether this was very, very broad. And I think there are certain companies that when they are doing legitimate data broker work, when they buy and sell broker data for fraud detection or other identity checks that definition as without the about a consumer could be a little too broad for their legitimate work. So the phrase about a consumer is meant to narrow it, narrow the exception to ensure that it's just about a consumer that is not considered publicly available information. That make sense?

[Unknown committee member]: Next

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: change. Start getting to the enforcement pieces.

[Michael Marcotte (Chair)]: So

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: this is the Data Broker Security Breach Act, which is Windham's bill since the introduction. The enforcement piece, the AG in the previous language, again this is new language, It's not in statute. The AG had the authority to conduct those fines through civil action and Tonderos requested that they have the similar authority and language be the same. But here's the decision you have to make. So paragraph two would be sufficient for BAG to adopt rules, conduct civil litigations, and basically enforce the Security Breach Act against adequate threat. The question is, do you want this to be also consumer protection cause of action? So subdivision one puts it into the Vermont Consumer Protection Act, two would give just the AG the authority to enforce against the Data Brokers. So curious what you all want to do here. The chapter is mostly includes both of these. It includes one and two. So I'm trying to make it theoretically, if I take another step back, this chapter already does this mistakenly. In my opinion, the chapter gives the entire, every section in this chapter is in the Consumer Protection Act. So, but I think we need to clean it up and be intentional on what we're doing. So the question is, do you want this specific part, these Data Brokers Security Breach Notice Act, do you want that to be within the Vermont Consumer Protection Act? This question, which gives the agency and the consumers the right to enforce.

[Unknown committee member]: I mean, that is the language that I think is used in a lot of legislation that we have around giving the attorney general the enforcement authority over the particular strategy. So I guess, and we have both of those one and two. One says, if you evaluate this subject, you evaluate the Consumer Price Protection Statute. And it almost seems by implication that would incorporate the enforcement provisions, but maybe just for clarity, we're having to.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: The calling it an unfair and setback is a big deal. When you say that a violation of this is an unfair and is a fact, that's major statement. That brings into play the consumer's right to enforce on their own a violation of this. So for some reason, data broker violates this act and has a breach and doesn't notify as they're supposed to, the AG and the consumer couldn't pursue action against that or broker. If you just have two, it would just be the AG that would have

[Unknown committee member]: the authority to Oh, I see, I get it. But one incorporates both, doesn't it?

[Michael Marcotte (Chair)]: Or not?

[Unknown committee member]: Yes,

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: I don't know if the AG would like just having one there because it is our statutes. I say army, truck of Vermont, right? We tend to use both of those in tandem and one's missing, that's a little bit weird.

[Unknown committee member]: Well, might be a negative.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Yeah, it means like, well, they intend to do this. Why they do this? Legislature intend to give the DG the right to adopt rules.

[Unknown committee member]: Gotcha, thank you. So I can

[Monique Priestley (Clerk)]: Yeah. Okay, this was a change I'm just seeing now. And so I guess, like, when we had gone over previous drafts with the civil piece that I was confused as to whether it seemed to me in my head, but I didn't bring it up, that this would limit the AG to just that versus the overall Consumer Protection Act. So this clarifies something. I don't know. I'm open to both committee things, but this does clarify in a way that I hadn't realized we could do.

[Unknown committee member]: Remember I had that question before, and so this definitely clarifies what I thought was maybe a bit of a gap there.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: And the previous language reflected the Security Brief Notice Act enforcement language, which is not what AG wants. They want something that's typically this, that's very clear that they have this authority under the Consumer Protection Act. So again, it's a policy choice. I'm also trying to clean up this chapter a little bit and make it so the consumers and the AG knows and businesses know what the remedies are. So again, up to you all how you do this. I can show you the rest of these so maybe it makes sense and kind of a bigger view of what I've done or what I'm suggesting.

[Unknown committee member]: Yes, yes.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Shall I proceed with what else I've done? Okay, so student privacy piece also not really amending here except for the enforcement language. And so again, like the current law is the entire chapter is subject to this, which doesn't make sense. I think it's a mistake, but it's what it is. So changing up the subchapter, which is just that student privacy teacher just passed over, I think, ten years ago, and adding in this AG authority. So Herb Olson said, we can't just have the first one. They've done that in the past. I think that was not done intentionally, to leave out the section where the AG has the same tool. So my suggestion is you give the AG the authority to adopt rules, conduct investigations, to match up everything else that's in this check.

[Unknown committee member]: Okay.

[Unknown committee member]: Just to make sure that I'm getting past you wouldn't want to have that, you wouldn't have the entire chapter subject to it because as time goes on, legislatures add new subchapters and you don't want to be explicit with each subchapter where it what you think should be appropriate as a enforcement. You want to have a sub chapter level and not the wrong chapter level. I just curious why I'm reading this paragraph as mistaken. Is that a bad practice or a less desirable practice?

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: So it's a good question. I think if you create a chapter intentionally with how you think it's going to go, for example, we're creating a data privacy chapter for genetic data privacy, so that chapter has been created. There's not a chapter wide, right, Vermont. There's this language in the Genetic Data Privacy bill that's

[Unknown committee member]: a sub chapter, because you

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: created a sub chapter within the chapter. So my answer to your question is, think what happened here is you had different sub chapters out of the different years, and these things happened in the last second. I think it was mistakenly called a chapter when it's in the sub chapter. So there are some chapters though where it was intentional, where you give the entire chapter the right or the same enforcement under the protection act or whatever the enforcement is for the rest of the school. Well, just kind of depends. It's my view that this should be, it's confusing. You guys can tell me that you don't want do it, that's totally up to you all. This is my suggestion and again, lost our chair.

[Monique Priestley (Clerk)]: I'll continue on. He united Kirk.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Right, so on to continuing on page 33, again this is enforcement language. This is in the data broker registration, this is where you're making a lot of changes. So the current enforcement is the AG may maintain a civil an action in the civil division of Superior Court to collect the penalties if posed in this section and to seek appropriate conjunctive relief. So here, the AG has requested, again, similar language to E, create an enforcement where this is the same language, That a person who abides supervision of the section, meaning the date of birth or registration, commits an unfair and subject of commerce and the AG can distinguish the money. So it's that same language being applied to the data broker registration. It's a policy choice. You don't have to give the AG or the consumers the right here, but it could keep it with the AAG just being able to get the penalties, which is the current law. You are increasing the penalties to a substantial amount of money. Currently it's what is $100 and the new version is going to be 1,000 or 900? So I

[Unknown committee member]: I think we had noted that there was a difference there in the way, because it was adding to a sub chapter. And when it was just a registration issue, to me anyway, the kind of enforcement seemed appropriate, but now that we're adding additional responsibilities, that's where I thought might wanna incorporate the other tools that the AG had in terms of enforcement.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Again, this is your call. You tell me what y'all want to do, but that's the current language. In the next section, I noticed this last time that You have the right language for the time. This is 2447. This is existing law. These are standards that the data brokers must maintain to protect user personal information. The mistake is again this should be section not chapter because you're talking about the section that 2.47 not the entire chapter 62.

[Unknown committee member]: All right,

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: In the study, I just have one remaining thing and that's whether or not you want to appropriate money for the study or the Secretary of State to conduct. I don't know if I got your answer on that last time. So do you want to appropriate money or do you want to remove that from the bill? And that is amendments to this latest version.

[Monique Priestley (Clerk)]: Yeah. We did. I was showing was that 50 to 70 or something? It's in his it's in his testimony.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Yeah. But that was special.

[Monique Priestley (Clerk)]: It was yeah. It was a ballpark figure. Yeah.

[Michael Marcotte (Chair)]: Did I get in touch with David?

[Monique Priestley (Clerk)]: He had, yeah, he had it in his testimony.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Okay.

[Michael Marcotte (Chair)]: Any questions?

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Can I get some direction on the enforcement piece? Are you all okay with that? Okay. Yeah. Well I just When Legg Council does something, I just want to make sure you guys are okay because it's not I mean I'm noticing how it's not the same and look you are giving consumers rights here so I just want to make that clear. Okay.

[Michael Marcotte (Chair)]: Anything else? Perfect. Bring up the same problems I've had.

[Monique Priestley (Clerk)]: We do have a witness too.

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: Hi, Eve.

[Monique Priestley (Clerk)]: Hello.

[Michael Marcotte (Chair)]: Thank you for joining us this afternoon.

[Eve Maler (Witness, Venn Factory; former CTO, ForgeRock)]: It's a pleasure. Thank you, chair Marcotte and vice chair Graning and the members of the committee. So I'm Eve Mailer. I'm the founder and president of digital identity advisory firm, Ven Factory, and I'm also author of the forthcoming book, mastering digital identity from risk to revenue. I've been in the digital identity sector since the year 2000 when I worked with colleagues across the industry to start and run the committee that designed the SAML standard, security assertion markup language. That was the first open standard for single sign on across business entities. Most recently, I was the chief technology officer for ForgeRock, an identity and access management platform provider serving banks, government agencies, health care providers and payers, and many others. In 2016, I testified to the API Privacy and Security Task Force of the US Health and Human Services Office of the National Coordinator. I wanted to thank Representative Priestley for sharing some questions with me ahead of time to ensure that I addressed issues of concern. Let me please start with some background on Know Your Customer, or KYC. KYC is a legal requirement under the Bank Secrecy Act. It obliges financial institutions to confirm the real world identity of their customers. In other words, to establish that a person is who they say they are before opening accounts or conducting transactions. Its purpose is to prevent prevent financial crime, money laundering, fraud, and the financing of illegal activity. That's a real and important obligation. In technical terms, what KYC requires is called identity verification, sometimes shortened to IDV. What it does not require is any particular method of verification. A bank can satisfy its KYC obligations using a driver's license scan, a biometric match against a passport, or a government issued digital credential. It can also use a quiz drawn from a data broker's database. But that approach, known as knowledge based verification or KBV, is the one that federal security standards have now explicitly prohibited. KBV questions look like, what street did you live on in 2010? What's your mother's maiden name? What was your first car? All of that information exists in data broker databases. That's where the questions come from. I'll come back to why that's a problem. The reason this distinction matters is that we've been hearing that financial institutions need broad access to data broker data for KYC. That framing is accurate in the sense that KYC requires verification, but it conflates the legal obligation with one specific and outdated implementation choice. KYC doesn't require data broker data. Some institutions have chosen to use data broker data for a particular approach to KYC. That's an approach that federal guidelines have moved away from, and that move away is not the same thing as KYC being impossible with data data brokers without data brokers. I'll stop there and see if there are any questions. No? Okay. So I want to tackle the question of why the National Institute of Standards and Technology, NIST, no long no longer considers KBV to be strong evidence for identity verification. If an institution is using KBV, it means they're using an approach that this top technical standards body has formally abandoned. In fact, this current guidelines, were updated in August 2025, now explicitly prohibit KBV for identity verification. So an institution still relying on it is behind the curve on security, not leading it. So you might wonder if a financial institution is buying data broker data to perform KBB, what does that mean for the integrity of the verification process? Well, it means that the supposed secret underlying the method isn't secret anymore. KBV only works if the answers are known to the applicant and no one else. Data broker databases have been breached repeatedly, most dramatically in 2024, when a single breach allegedly exposed up to 2,900,000,000 records on an estimated 170,000,000 people in The US, The UK, and Canada. So if a fraudster can buy the same answers that the verification system expects, the quiz doesn't distinguish between the real person and an impostor. Let's look at the implications of KBV specifically on security. What does the continued use of this method for KYC tell us about the security posture of banks and insurers who are still using it? It tells you that they're optimizing for low cost, not for security or even for a smooth and pleasant user experience as you might have experienced yourself. KYC is a legal compliance requirement, and how you meet it is a choice. So using quiz questions based on purchasable consumer data data is one of the cheapest ways to check a KYC box and one of the weakest from both the security and usability standpoints. Better alternatives exist. Institutions that aren't using them have made a deliberate trade off. Let's look at the quality of the personal data in these systems. How accurate and current is all this personal data that flows through commercial data brokers? Well, the data is unreliable by its very nature. Brokers aggregate data from many sources without authoritative correction mechanisms. So records go stale and errors propagate. There was a 2019 peer reviewed study that found that at least 40% of data broker attributes were inaccurate, and an FTC report reached similar conclusions. So no federal audit standard has been established in the years since either finding, and a consumer typically has no way to know their record is wrong, let alone let alone fix it. Let's look at potential alternatives, as I mentioned. What verification methods have replaced KBV in modern financial services, and are they available to smaller institutions? Document verification, like I mentioned, scanning a driver's license or a passport combined with a live photo match, has become the baseline for secure identity verification. It is available to institutions of any size through pay per transaction vendor services. Now KYC quality document verification typically runs about $1 per check. Knowledge based verification runs about 20 to 50¢ with volume discounts that can reach 10¢ at scale. That gap is real, and smaller institutions that can't negotiate volume discounts will feel it more acutely than large ones. The economics look different, however, once you account for fraud exposure and for the hidden costs within KBV itself. For example, when a user mistypes an answer, which happens regularly, the system triggers manual review, which costs more than the automated check and can take up a day up to a day to to resolve. So that degrades both the economics and the customer experience. Let's look specifically at the needs of these smaller financial institutions. If a smaller institution needed to transition away from KBB, is that technically feasible, and does it improve security? I would say the answers are yes and yes. The technical work is integration, connecting to an existing vendor service, and it's a bounded and solvable problem, not a novel engineering challenge. And the resulting security posture is substantially better. Document verification is much harder to defeat than a quiz based on purchasable data because the attacker needs the physical credential, not just information they can buy. Now you might wonder what happens if a consumer deletes their data from a broker? Do things break? The concern, I would say, is less substantial than it sounds for two compounding reasons, one practical and one analytical. The practical one, complete deletion from the data broker ecosystem is actually very difficult to achieve. Brokers use each other as data sources, so the same attributes tend to propagate across multiple databases. A deletion from one broker typically leaves the same record intact in others that sourced from it or share the same upstream inputs. The disruption to KBV pipelines that critics warn about is therefore largely theoretical. Now the analytical challenge is that even if deletion did succeed, the data being retained was either, inaccurate or accurate, and neither scenario supports keeping it. Inaccurate data was already generating wrong verification outcomes, so removing it is a correction, not a loss. Accurate data is exactly what a fraudster wants to acquire. Its continued presence in a broker database isn't protective. It's a standing liability. So the risks run-in different directions, but the conclusion is the same. The case for retaining this data in a broker's hands is weaker than the deletion concern implies. Is it reasonable for a financial institution or an insurer to argue at this point in 2026 that they can't operate without broad unrestricted data broker access? And I would say no, not for KYC compliance purposes. As I've said, NIST has explicitly prohibited KBB, the primary use case being mooted, since 2025, and alternatives are commercially available. The argument is better characterized as a preference for low cost legacy workflows than a general, operational necessity. Narrow purpose based exemptions for specific legitimate uses, fraud detection or sanction screening, can be evaluated on their merits. And as I understand it, the bill that you're working on has already done the careful work of identifying which uses justify overriding a deletion request. And maybe finally, I'll just conclude with some thoughts about what happens to deceased person's data in broker databases and what risks does that create. Deceased individuals' records persist indefinitely in most broker databases. Brokers have no authoritative real time connection to official death records. That stale data creates two distinct risks. The first is identity fraud. A deceased person's KBB answers still work, and their data can be used to open fraudulent accounts or to impersonate them in scams targeting surviving family members. The second is operational error. Incom incorrect or incomplete death records cause problems in legitimate claims processing. And both argue for better data sourcing, not more data accumulation. And where I'm coming from on this matter is that I co chair a group called Death and the Digital Estate, DAID, at the OpenID Foundation, which recently published a white paper on the relevant topics here. And I'll provide you with all of these resources. With that, I'll see if there's any questions that I can answer.

[Monique Priestley (Clerk)]: Great. Yeah. Thank you so much, Eve. Just one, because we have a related bill as well just for the future, but also just considering future KYC stuff around, like, mobile driver's licenses and IDs. And I know that's been, you know, at the past in Utah and it's been discussed in other states. Like, I'm just curious on your thoughts about mobile IDs.

[Eve Maler (Witness, Venn Factory; former CTO, ForgeRock)]: Yeah. So mobile driver's license license technology is instance of what's known as decentralized identity and verifiable credentials in the identity industry. And that's new technology, relatively new, that's come onto the scene for delivering verification drivers in a reusable fashion. So let's examine that. Mobile's driver's licenses are a promising direction, but I'll note that Vermont hasn't deployed them yet, and they're not a prerequisite for institutions that want to transition away from KBV today. A financial institute verifying identity through a standard vendor API against a physical driver's license or a passport doesn't strictly need an MDL program, so that path is available now. Any further questions?

[Unknown committee member]: Yes, thank you very much. So I think what I'm largely hearing is that arguments against the legislation that pertain to what we have to do to know your customer, we have to do these things. You're saying, one, this is saying this is not the best way to go about things. It's also, as you said, it's preference and we hear a lot of votes, well, that's a cost we have to pass along to the consumer. And I usually just spend a little more time on the viability of those alternatives that you were describing, make sure I'm understanding them well. I think the overall one is that when your customer goes back fifty some odd years or something like that, and there was a way in which we're looking at an early iteration of how it made sense to do that work. We have crossed that rutabacon 30 times over technologically, we still are using, okay, and so an older approach, an approach from a made merry RFD sort of era. What I'm also trying to get at is, is that doomed to happen to every single data type that we might be looking at technologically, that they become relics that sort of, I don't believe they're usefulness?

[Eve Maler (Witness, Venn Factory; former CTO, ForgeRock)]: Yeah. So the challenge with cybersecurity and with fraud, which is a close cousin, is that it's an arms race, so

[Monique Priestley (Clerk)]: to

[Eve Maler (Witness, Venn Factory; former CTO, ForgeRock)]: speak. And bad actors are improving their techniques. Like, one of the techniques is AI deepfakes, for example, which can also impact things like the recognizing of things like passports and physical driver's licenses. So they're not immune either from this kind of degradation over time. You may be familiar with SMS OTP, so, you know, texted one time passwords that we frequently get. That's another method that NIST has deprecated over time. And, you know, we could be grateful that NIST has been keeping up with the technology and also that, KYC rules do not specify the method so that we can keep up as different methods degrade over time. So right now, there's, quite a lot of innovation in the identity verification space. We did not have some of the biometrically rooted methods five years ago, and they've been innovating very quickly. And so now that those are coming online, they are not only becoming available to smaller and smaller institutions, but there's price pressure downward as well. I will mention, from my experience working with retailers, so not necessarily under a KYC requirement, but they often have a need to do identity verification. It used to cost maybe $5.10, $15 per verification, but getting that customer on board was so valuable, it was worth the price of admission, so to speak. So it is possible for the trade off in terms of security protection and fraud protection to be so great that even a $1 cost or even a little more than a $1 cost, which might be going down soon enough, might be quite available, especially to smaller institutions who are not onboarding that many new bank customers in any one month or year.

[Michael Marcotte (Chair)]: Thank you very much. We're being called to the floor now, so we have to go. But we appreciate you taking the time to talk with us today.

[Eve Maler (Witness, Venn Factory; former CTO, ForgeRock)]: Thank you so much.

[Michael Marcotte (Chair)]: Thank you. We're on the floor. The civil committee knows I was hoping that the vice chair was going to be able to make it in so that we could have her on the floor to assist us with 05:12. Unfortunately, she's still under the weather, so we're gonna delay action for one day. Okay. And take it up tomorrow. I talked to talked to the vice chair. She expects that she'll be feeling better tomorrow. So we'll delay the action on that one day, two days up. Two days, yep.

[Monique Priestley (Clerk)]: It's gonna be a busy Friday. Tomorrow

[Michael Marcotte (Chair)]: 02/2005, we'll be hearing from Pietro Lin. He's a lawyer that deals with collective bargaining.

[Monique Priestley (Clerk)]: He used to be the NEA guy, didn't he,

[Unknown committee member]: back in the day?

[Unknown committee member]: Know. Not. Yeah. So he'll

[Michael Marcotte (Chair)]: be coming in to talk to us tomorrow afternoon. Great. He will be him up at 02:30. We we yeah. We've we had an email from Addison online, and his email address Okay. Is in So I think we'll have that conversation to better understand. I think we haven't really haven't heard from superintendent side of this yet, and so it's giving us an opportunity to hear.

[Monique Priestley (Clerk)]: Does he typically work with superintendents?

[Unknown committee member]: I That's

[Michael Marcotte (Chair)]: where he's coming from. So

[Rick Sable (Legislative Counsel, Office of Legislative Counsel)]: He so he He's a former used

[Monique Priestley (Clerk)]: to be a superintendent. Sorry. Go ahead.

[Michael Marcotte (Chair)]: Sure. But he owns the the firm that does most of the the attorney work for for schools, at least our district he does. So we'll hear from him tomorrow at 02:05. There? Right. Maybe we can grab something.

[Unknown committee member]: You see my chart? Yes.

[Michael Marcotte (Chair)]: We will go offline. We're off to the floor, and we'll be on at nine tomorrow morning.