To answer the cybersecurity section of a state money transmitter exam, write one answer per control, map each answer to 16 CFR 314.4 (the FTC Safeguards Rule) and to the state's own law, and attach dated evidence an examiner can test. Keep that answer set in one library, reuse it in every state, and change it only when the evidence changes. Most of the work is evidence, not prose.
Key takeaways
- 16 CFR 314.2 names wire transferors and check cashers among the businesses the FTC Safeguards Rule covers, so 314.4 is the backbone most money transmitter security questions trace back to.
- 314.4(d)(2) offers a choice: effective continuous monitoring, or an annual penetration test plus vulnerability assessments at least every six months and after material changes. Say which you chose and prove it.
- The CSBS Money Transmission Modernization Act (MTMA), enacted in full or in part by 31 states according to CSBS, authorizes joint exams, acceptance of another state's report and multistate record standards. Your answers travel between states.
- Build the library around controls, not questionnaires: answer, clause, evidence, owner and the date it was last true.
- Vulnerability and third-party software answers drift fastest. Tie them to live records, not to last year's document.
- Safeguard covers this with its Compliance and GRC suite (GA) including the GLBA framework and Questionnaires, vulnerability management (GA), TPRM (GA), bulk export (GA) and a Trust Center (GA). People still sign, submit and talk to the examiner.
The situation
The examination notice arrives from your home state regulator, or from a lead state on behalf of several. It sets a date for the first day letter or the document request, and somewhere in the request list sits an information technology or information security questionnaire. It asks how you identify and fix vulnerabilities, how you develop software, how you choose and monitor vendors, who your Qualified Individual is and what that person reported to the board last year.
You hold licences in many states. Last year another state asked similar questions in different words, and someone answered from memory. A sponsor bank sent its own questionnaire, and engineering answered that. You now have three answer sets to roughly the same questions, and at least one is no longer true.
A bad week looks like this. The examiner asks for the last two vulnerability assessment reports and remediation evidence for every critical finding. You find one report and a spreadsheet with no closure dates. The examiner asks for the third-party software in the system that holds customer data, and nobody has a list. Then your patch timeline answer is compared with the one you gave another state eighteen months ago, and they do not match.
The pattern hurts: answers that cannot be tested, evidence rebuilt from scratch, and inconsistency across states that share information. The goal here is to stop rebuilding.
This post interprets public regulatory text to help you organise your work. It is not legal, regulatory or audit advice. State laws differ, and your counsel and your examiners are the authority on what applies to you.
Which rules apply to a money transmitter's information security
Three layers usually sit behind an examiner's cybersecurity questions: the state money transmission law (in many states now based on the MTMA), the FTC Safeguards Rule, and any state cybersecurity rule that applies to your licence. Contracts with sponsor banks and card networks add a fourth layer that is not law but often asks the same questions.
State money transmission law and the MTMA
Money transmission is licensed state by state. The Conference of State Bank Supervisors (CSBS) describes the MTMA as a single set of nationwide standards for money transmitter supervision, approved for state adoption by the CSBS Board. On its MTMA page, dated 3 September 2026, CSBS says thirty-one states have enacted the law in full or in part, and that licensees in at least one adopting state account for 99% of reported money transmission activity. The same page notes that uneven adoption and interpretation have led to variation in how examiners apply it, which is why CSBS now runs a guidance request process.
The model act's text matters for exam preparation in four places:
- Section 4.03(a) lets the regulator examine a licensee on site or off site, examine jointly with other states or federal agencies, and accept another state's or a federal agency's examination report as its own.
- Section 4.03(b) requires the licensee to give the regulator full access to the records it reasonably requires, at the location and in the format the regulator specifies, and lets the regulator use multistate record production standards.
- Section 4.04 authorizes and encourages the regulator to take part in multistate supervision coordinated through CSBS and the Money Transmitter Regulators Association (MTRA), and to share information with other state and federal regulators. It also says joining multistate supervision never waives the state's own authority to examine.
- Section 7.06 sets the core records a licensee must keep for at least three years (bracketed in the model, so states may change it), including any other records the regulator reasonably requires.
The model act's commentary also names information security among the functional areas whose policy owners count as key individuals. Otherwise the MTMA is mostly about capital, bonding, permissible investments and licensing. It explains why exams are coordinated and why records arrive in a specified format; the technical substance comes from the next layer.
The FTC Safeguards Rule, 16 CFR Part 314
The Safeguards Rule applies to financial institutions under the FTC's jurisdiction that are not otherwise subject to another GLBA regulator. The current eCFR text of 16 CFR 314.2 lists wire transferors and check cashers among the businesses it covers, and gives the example that a business that regularly wires money to and from consumers is a financial institution because transferring money is a financial activity. For most non-bank money transmitters, that settles which federal security rule is in play.
Section 314.4 lists the elements of the information security program. In the order the rule gives them:
| Clause | What the rule requires (summarised) | What an examiner will usually want to see |
|---|---|---|
| 314.4(a) | A Qualified Individual who oversees and enforces the program; if outsourced, you keep responsibility and name a senior person to oversee them | Appointment record, job description, board minutes |
| 314.4(b) | A written risk assessment with criteria for evaluating risks and for how risks are mitigated or accepted, repeated periodically | The current risk assessment and the previous one |
| 314.4(c)(1) | Access controls, reviewed periodically | Access review records |
| 314.4(c)(2) | Identify and manage the data, personnel, devices, systems and facilities that matter to the business | Asset and system inventory, including software |
| 314.4(c)(3) | Encrypt customer information in transit over external networks and at rest, or use compensating controls approved by the Qualified Individual | Encryption standard, exceptions with approvals |
| 314.4(c)(4) | Secure development practices for in-house applications, and procedures to evaluate or test externally developed applications | SDLC policy, code review and testing records, third-party software review |
| 314.4(c)(5) | Multi-factor authentication for anyone accessing any information system, unless the Qualified Individual approves an equivalent control in writing | MFA coverage report, written exceptions |
| 314.4(c)(6) | Secure disposal and data retention review | Retention schedule, disposal records |
| 314.4(c)(7) | Change management procedures | Change records for a sample period |
| 314.4(c)(8) | Monitor and log authorized users' activity | Logging and monitoring design, alert samples |
| 314.4(d) | Regularly test or monitor the effectiveness of key controls; see the next section | Test plan, results, remediation |
| 314.4(e) | Security awareness training and qualified security staff | Training records, staff qualifications |
| 314.4(f) | Select capable service providers, require safeguards by contract, assess them periodically based on risk | Vendor inventory, contracts, assessments |
| 314.4(g) | Adjust the program based on testing, changes and risk assessments | Change log for the program itself |
| 314.4(h) | A written incident response plan covering seven listed areas | The plan, test or tabletop records |
| 314.4(i) | The Qualified Individual reports in writing at least annually to the board or equivalent | The last report and the board's record of it |
| 314.4(j) | Notify the FTC within 30 days of discovering a notification event involving at least 500 consumers | Procedure and any notices filed |
Two details are easy to miss. Section 314.5 says 314.4(j), the FTC notification duty, took effect on 13 May 2024. Section 314.6 exempts institutions holding customer information on fewer than five thousand consumers from 314.4(b)(1), (d)(2), (h) and (i). If you rely on the exemption, say so and show the count.
What 314.4(d)(2) requires on monitoring, penetration tests and vulnerability assessments
This is the clause behind most "how do you manage vulnerabilities" questions, so it is worth reading closely. Section 314.4(d)(1) requires you to regularly test or otherwise monitor the effectiveness of your key controls, systems and procedures. Section 314.4(d)(2) then says that for information systems, the monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments.
If you do not have effective continuous monitoring, or other systems that detect on an ongoing basis changes in information systems that may create vulnerabilities, the rule sets two floors:
- Annual penetration testing, scoped each year on relevant risks identified in your risk assessment (314.4(d)(2)(i)).
- Vulnerability assessments, including systemic scans or reviews reasonably designed to identify publicly known security vulnerabilities, at least every six months, whenever there are material changes to operations or business arrangements, and whenever circumstances may have a material impact on the program (314.4(d)(2)(ii)).
The rule does not say continuous monitoring replaces everything else, and it does not define continuous monitoring. Your answer has to make a claim and support it. If you claim continuous monitoring, the examiner will test whether it really detects changes that may create vulnerabilities, on an ongoing basis, across the systems in scope. If you rely on the periodic route, the examiner will count reports and dates.
A strong answer does both: it explains the continuous monitoring you run, and it still produces dated vulnerability assessment reports at least twice a year and an annual penetration test, so the answer holds whichever reading the examiner takes. NIST SP 800-40 Rev. 4, the federal guide to enterprise patch management, frames patching as preventive maintenance and describes the cycle as identifying, prioritizing, acquiring, installing and verifying patches. Using its vocabulary in your procedure gives the examiner a familiar yardstick.
Third-party software belongs inside this answer. Publicly known vulnerabilities in your information systems include those in the open source libraries and vendor components your own applications ship. If your assessment covers servers and network devices but not the dependencies inside your transfer platform, say what covers them, or expect the follow-up. Our post on how often you must scan under the FTC rule and NYDFS goes deeper on frequency.
State cybersecurity rules on top
Some states add their own cybersecurity regulation. New York's 23 NYCRR Part 500 is the best known. It defines a covered entity as anyone operating under a licence or similar authorization under New York's Banking Law, Insurance Law or Financial Services Law. If your New York licence brings you inside that definition, three sections sit right next to your FTC answers (section numbers from the department's published text of the Second Amendment, which it marks as an unofficial version):
- 500.5 Vulnerability management requires written policies that ensure, at a minimum, penetration testing from inside and outside the system boundaries by a qualified party at least annually; automated scans plus manual review of systems the scans miss, at a frequency set by the risk assessment and promptly after material system changes; a monitoring process that tells you promptly about new vulnerabilities; and timely remediation prioritised by risk.
- 500.11 requires a written third-party service provider policy covering identification and risk assessment of providers, minimum practices, due diligence and periodic assessment.
- 500.17 requires notice to the superintendent within 72 hours of determining a cybersecurity incident has occurred, and an annual certification of material compliance (or an acknowledgment of non-compliance) by 15 April.
Notice how close 500.5 is to 314.4(d)(2), and how it differs: New York sets annual penetration testing and risk-based scanning without the FTC rule's continuous monitoring alternative. One canonical vulnerability answer can satisfy both if it describes the annual test, the scan frequency and the prompt rescans after change.
CSBS has also published a Nonbank Model Data Security Law; a December 2024 CSBS post says Minnesota was the first state to adopt it together with the MTMA. Check each licensing state for an adopted version. The FTC rule is the floor everywhere; state rules add to it. Build the library on the floor, then add state fields.
How multi-state exams are coordinated and what examiners ask
State regulators coordinate through what CSBS calls Networked Supervision. CSBS describes three platforms: the Nationwide Multistate Licensing System (NMLS) for licensing, the State Examination System (SES) that connects agencies and companies for examinations, and CSBS Data. On that page CSBS contrasts the old model, where institutions faced separate exams from each state, with the current one, where states work together on a single comprehensive exam and the institution deals with one point of contact.
The MTMA's Section 4.04 gives the legal footing for that cooperation in adopting states, through CSBS and the MTRA. In practice that means three things for you:
- Your answers travel. A joint exam or an accepted report means several states see the same answers at once, and information sharing means a later exam can see earlier ones.
- The request list may arrive through SES. CSBS describes SES as the online platform connecting state agencies and the companies they examine, so expect to upload documents there rather than email them.
- Duplicate requests are a known problem. In a 2024 CSBS blog post about a multistate mortgage pilot under the One Company, One Exam protocol, a state examiner described finding multiple, duplicate requests that states had added, often because each state phrased a familiar question its own way. That example is from mortgage supervision, not money transmission, but the lesson carries: you will see the same control asked in different words, and the answer should be the same.
Questions usually follow the shape of 314.4: governance (Qualified Individual, board reporting, policies), risk assessment, inventory, access and MFA, encryption, secure development and change management, vulnerability management and testing, logging, vendors, incident response and, increasingly, ransomware readiness. CSBS publishes a Nonbank Ransomware Self-Assessment Tool, now version 2.0, built with the Bankers Electronic Crimes Taskforce and the US Secret Service; CSBS says it gives management and the board an overview of ransomware preparedness and may help regulators who review your practices.
There is no single standard questionnaire to memorise. The request list belongs to the examining state and changes, so prepare the substance and let the wording vary.
Step by step: build the answer set this week
These steps work with a spreadsheet, a document store and your existing ticketing system. Nothing here needs a particular tool.
- Collect every questionnaire you have answered. State exams, sponsor bank due diligence, processor and network questionnaires, insurance applications, customer reviews. Note the date and who answered.
- Break them into atomic questions. One row per question. Many will be the same question in different words.
- Map each question to a control. Use 16 CFR 314.4 as the spine, because it applies to you in every state. Add a column for the state rule (for example a Part 500 section if you hold a New York licence) and one for the contractual source (sponsor bank, network).
- Write one canonical answer per control. Plain, specific, testable. Say what you do, how often, who owns it and what record proves it.
- Attach evidence to each answer. A file, a system export or a link to a live record, each with a date. If no evidence exists, the answer is not ready.
- Mark the volatile answers. Vulnerability counts, open findings, vendor lists, MFA coverage and patch timelines change often. Give them a refresh date and an owner.
- Run a consistency check. Compare the canonical answer with what you told each state and each partner in the last two years. List every difference and decide whether the old answer was wrong, out of date or just phrased differently.
- Get sign-off. The Qualified Individual and, where relevant, counsel approve the canonical answers. Record who approved which version and when.
- Answer the current exam from the library. Copy, adapt the wording to the question asked, and do not change the substance without changing the library.
- Log what you sent. Keep the exact text and evidence you submitted to each state, with the date, so the next exam starts from the record and not from memory.
Template: one row in the answer library
| Field | Example (illustrative) |
|---|---|
| Control ID | VM-02 Vulnerability assessment of applications and dependencies |
| Rule references | 16 CFR 314.4(d)(2)(ii); 314.4(c)(4); state rule section if any |
| Contract references | Sponsor bank due diligence item; processor questionnaire item |
| Canonical answer | We scan all production applications and their open source dependencies daily and after each release. Findings are triaged within two business days and fixed to the timelines in the vulnerability management standard. A full vulnerability assessment report is produced at least every six months and after material changes. |
| Evidence | Last two semi-annual reports (dates); remediation log for criticals in the period; the standard (version, approval date) |
| Owner | Head of Security Engineering |
| Volatile? | Yes: refresh before each exam |
| Last verified | Date and name |
| Sent to | State A exam (date), State B exam (date), sponsor bank (date) |
The numbers in the example are placeholders. Use your own standard's timelines, and do not promise a timeline you do not meet.
Decision table: continuous monitoring or periodic route under 314.4(d)(2)
| If this is true | Then answer this way | Evidence to attach |
|---|---|---|
| You scan applications, dependencies and infrastructure on an ongoing basis and can show detection of new vulnerabilities as they are disclosed | Claim continuous monitoring, describe scope and frequency, and still show periodic reports | Scan coverage list, sample alerts with dates, remediation records, the last two assessment reports |
| You scan on a schedule (monthly or quarterly) without ongoing detection | Take the periodic route: annual penetration test and vulnerability assessments at least every six months and after material changes | Pen test report and scope, assessment reports with dates, change log showing reassessment after material changes |
| Coverage is partial (for example infrastructure scanned continuously, application dependencies only at release) | Describe each part honestly and do not claim continuous monitoring for the whole | Coverage matrix by system, plan and date to close the gap |
| You hold customer information on fewer than five thousand consumers | You may rely on 314.6 for (d)(2), but most examiners will still ask how you find vulnerabilities | Consumer count method and date, and whatever testing you do |
How to build one answer library for every state
The library is a set of controls, not questionnaires. Questionnaires change; the controls behind them do not, and 314.4 gives you the same spine in every licensing state.
Organise it in three layers:
- Layer 1, the control and its canonical answer. Written, approved and versioned once: text you are willing to see quoted back in any state.
- Layer 2, the mappings. The rule clauses and contract items each control satisfies. A new questionnaire becomes a mapping exercise.
- Layer 3, the state and partner deltas. Where a state asks for something extra, record it as an addition to the control, not a separate answer that can drift.
Three habits keep it honest:
- Version the answers. Substance changes mean a new version, date and approver. Record which version each exam received.
- Separate answer from evidence. The answer can stay stable for a year while the evidence refreshes every quarter.
- Write to be tested. Examiners sample. If an answer promises a fix time for criticals, expect them to pull criticals and check dates.
Ownership matters as much as structure. The GRC lead owns the library and mappings, control owners own their answers and evidence, and the Qualified Individual approves. Engineering should not write exam answers from scratch, and compliance should not invent engineering facts.
What evidence backs each answer
Examiners test answers by asking for records. Every item needs a date and a source system.
| Area | Typical question | Evidence that answers it |
|---|---|---|
| Governance | Who is the Qualified Individual and what did they report to the board? | Appointment record; last annual written report under 314.4(i); board minutes noting it |
| Risk assessment | Show your written risk assessment and when it was last updated | Current and prior risk assessment with criteria (314.4(b)(1)); risk register with treatment decisions |
| Inventory | What systems and software hold customer information? | System inventory; software inventory per application, including open source components (SBOMs where you have them) |
| Vulnerability management | How do you find and fix vulnerabilities? | Standard with timelines; scan coverage; the last two assessment reports; remediation log for high and critical findings; exceptions with approvals and expiry dates |
| Penetration testing | When was your last penetration test and what did you fix? | Report and scope; remediation tracking to closure; retest evidence |
| Secure development | How do you develop software securely? | SDLC policy; code review and testing records for a sample of changes; dependency checks in the build |
| Change management | Show changes to production for a period | Change records with approvals and tests |
| Vendors | How do you select and monitor service providers? | Vendor inventory with risk tiers; contract clauses requiring safeguards; periodic assessments (314.4(f)) |
| Incident response | Show your plan and the last test | Plan covering the 314.4(h) areas; tabletop or test record; lessons learned |
| Breach notice | How would you notify the FTC? | Procedure for 314.4(j); any notices filed |
Three kinds of evidence carry the most weight: system generated records (scan results, ticket histories, access review exports), approvals with names and dates (risk acceptances, exceptions, policy approvals), and before and after (a finding, its fix and the rescan). A dashboard screenshot proves only today; export the history for the exam period.
How sponsor bank and card network requirements overlap
Many money transmitters and payments fintechs also work with a sponsor or partner bank, and with card networks or processors. Those relationships bring their own questionnaires. They are contractual, not statutory, but they ask many of the same things.
The Federal Reserve, FDIC and OCC issued their Interagency Guidance on Third-Party Relationships: Risk Management on 9 June 2023. It sets out sound risk management for every stage of a bank's third-party relationships, scaled to risk and complexity, and replaced each agency's earlier guidance. A fintech partner meets that guidance as the bank's due diligence questionnaire, its audit rights and its monitoring requests; our posts on what a sponsor bank needs from a fintech on open source risk and whether the 2023 guidance applies to fintechs cover the bank's side. If you handle cardholder data, the payment card industry's security standard (PCI DSS, with v4.0.1 listed in the PCI Security Standards Council document library) brings its own requirements for vulnerability management and secure software, usually checked through a validation the network or acquirer requires.
The overlap with your state exam answers is large:
| Topic | State exam (via 314.4) | Sponsor bank | Card data security standard |
|---|---|---|---|
| Vulnerability management | 314.4(d)(2) testing and assessments | Asks for your program and recent results | Has its own scanning and patching requirements |
| Secure development | 314.4(c)(4) | Asks for SDLC and testing evidence | Has its own secure software requirements |
| Vendors | 314.4(f) | Asks for your subcontractor oversight | Asks about service providers that touch card data |
| Incident response | 314.4(h), (j) | Contract notice duties to the bank | Its own incident procedures |
| Board reporting | 314.4(i) | May ask for the report | Not usually |
Treat these questionnaires as more mappings onto the same controls. When a bank asks for something stricter (a shorter patch window, say), consider adopting it everywhere: one standard is easier to evidence, and an examiner who sees a stricter promise to a bank will ask why. Where answers differ for good reason, such as a card standard scoped to the cardholder data environment, write the scope into the answer.
What remains the licensee's job
No tool and no consultant takes these off you:
- Licensing filings. NMLS filings, reports of condition, change of control notices and reports of certain events.
- Examiner correspondence. The first day letter, the request list, explanations and responses to findings.
- State-specific rules. Which states adopted the MTMA in what form, which have a data security law or cybersecurity regulation, and what each adds to the FTC floor.
- Judgment and sign-off. Choosing the 314.4(d)(2) route, accepting risk, approving exceptions, signing the board report and any annual certification.
- Notifications. Deciding whether an event triggers 314.4(j), 500.17 or a state breach law, and filing on time.
- Truth. A tool can draft; a person attests that every answer is true for its period.
How Safeguard does this
Everything below comes from Safeguard's offering documentation and its public docs at docs.safeguard.sh. Screens are named only where the docs name them.
- Turn on the GLBA framework in the Compliance and GRC suite (GA). The suite's tabs include Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center and Connectors. Safeguard's GLBA framework page says the framework is on in your workspace unless you switch it off in Compliance › Manage. It lists scan requirements tied to clauses of 16 CFR 314.4, including the inventory duty in 314.4(c)(2), secure development in 314.4(c)(4) and service provider oversight in 314.4(f), plus catalog controls for areas such as the Qualified Individual, monitoring and testing, incident response, annual board reporting and MFA. Use those controls as the spine of your answer library.
- Scan your products so the software inventory is real. Safeguard builds a software inventory (SBOM) for each product it scans, through SBOM generation and analysis (GA) and SCA (GA), and the GLBA scan requirements are checked against that inventory. That gives you the third-party software list an examiner asks for under 314.4(c)(2) and (c)(4), per application.
- Track findings in vulnerability management (GA). The docs describe daily continuous scanning of all your projects, re-evaluated when new CVEs are published. Each record carries the CVE ID, CVSS, EPSS, known exploitation (CISA KEV), affected component and version, fixed version, references and reachability, and prioritisation weighs exploitability, reachability analysis (GA) and business context. That is the raw material for your 314.4(d)(2) and 500.5 answers and the remediation log examiners sample.
- Record decisions where the examiner can see them. On a vulnerability, Accept Risk takes an expiration date and a business justification and goes for approval; Mark False Positive takes a justification and goes for approval if your policy requires it. On Compliance › Risks, a low or medium residual risk can be accepted by its owner, while a high or critical one needs an approver with an admin role and a review date within a year. If the risk later rises, the acceptance shows Needs re-approval. These are the dated, named approvals that make an exception defensible.
- Keep vulnerable versions out of releases with policies and gates (GA). Gates enforce your rules at checkpoints with the actions Block, Warn and Notify; anything that needs a human sign-off runs through an exception. In an exam answer, that is how "we do not ship known critical vulnerabilities without approval" becomes testable.
- Collect and approve evidence. On Compliance › Evidence, evidence starts as submitted and a compliance reviewer chooses Accept or Reject, stamped with who, when and why. Changing accepted evidence creates a new version that goes back to submitted, and evidence with an end date shows as expiring and then expired. On Compliance › Policies, a policy goes to review with Submit for review; an approval covers one version, and the next review defaults to a year after approval.
- Reuse evidence across frameworks with the crosswalk. On Compliance › Crosswalk, a reviewer approves or rejects a mapping between two frameworks' controls. Approving an equivalent mapping makes accepted evidence for one control count toward the other in your programme. That is the mechanism behind one library serving the FTC rule and, where it is in your library, a state or card industry framework.
- Keep questionnaires next to the controls. The suite includes a Questionnaires tab, and Safeguard's offering describes questionnaire auto-answer in the Trust Center for standard formats such as SIG and CAIQ. A state exam questionnaire is not in those formats, so expect to map its questions to your controls yourself and use any draft only as a starting point that a person checks against the canonical answer and the evidence.
- Oversee suppliers in TPRM (GA). The Third Party Risk Manager keeps a vendor directory with contracts, SLAs and risk tiers; sends SBOM requests to suppliers with templates and tracked status; scores vendor risk; and monitors continuously for new critical vulnerabilities, KEV additions, risk changes and SBOM expiry. That is your 314.4(f) evidence: selection, contract, periodic assessment, ongoing monitoring.
- Export for the exam. Safeguard's bulk data export (GA) produces CSV, Excel, PDF, HTML, JSON and other formats, with filtering and column selection across tables. The compliance docs also describe pre-built reports, including a vulnerability summary, and custom reports: go to Reports, choose Create Report, select the framework, set scope and date range, then generate and export. Set the date range to the exam period so the export proves history, not just today.
- Publish to partners through a Trust Center (GA), if you want one. It is a public page where customers and partners check your posture; you choose the frameworks, controls, policies and documents shown, and restricted documents are released only through approved access requests. An examiner works from the request list, but a sponsor bank might use it.
- Let assistants prepare, and people decide. The approvals docs say Safeguard's AI assistant and MCP clients such as Claude can read your programme and prepare changes, but never approve, accept, launch or acknowledge anything, and an MCP client's writes run only after you confirm them.
Requirement, what Safeguard does, what you still own
| Requirement | What Safeguard does | What you still own |
|---|---|---|
| 314.4(b) risk assessment | Risk register on Compliance › Risks with acceptance rules by level | Writing the assessment, setting criteria, accepting risk |
| 314.4(c)(2) inventory | Software inventory per scanned product | Systems, data, devices and facilities outside the scan |
| 314.4(c)(4) secure development | Scan requirements, findings, gates with Block, Warn, Notify | Your SDLC policy, code review, testing practice |
| 314.4(d)(2) testing | Daily continuous scanning of projects, vulnerability records, exports | Penetration testing, infrastructure scanning outside scope, choosing the route |
| 314.4(f) service providers | TPRM directory, tiers, SBOM requests, monitoring | Contracts, due diligence decisions, onsite reviews |
| 314.4(i) board report | Reports and exports to build it from | Writing, signing and presenting it |
| State questionnaire | Questionnaires drafts, evidence, crosswalk | Reviewing, submitting, corresponding with the examiner |
What Safeguard does not do
- It does not file anything or talk to your regulator. NMLS filings, SES uploads, first day letter responses and examiner correspondence stay with you.
- It does not know your states' rules for you. The framework library covers federal GLBA; you confirm which states have adopted the MTMA, a data security law or a cybersecurity regulation, and map any extra state requirement yourself.
- It does not replace penetration testing. Vulnerability management and scanning support the 314.4(d)(2) answer, but if you rely on the periodic route you still need an annual penetration test from a qualified tester.
- It does not cover systems it does not scan. The software inventory and findings cover the products and projects you connect. Laptops, network devices, SaaS settings outside connected systems and third-party hosted services need their own evidence.
- It does not make questionnaire drafts true. Drafts need human review against your evidence. The assistant and MCP clients cannot approve, accept or sign anything, by design.
- It does not give legal advice or decide notification duties. Whether an event triggers 314.4(j) or a state breach law is a judgment for you and counsel.
- It does not fix vendors' own software. TPRM tracks what suppliers send and alerts you on new risk; fixing a supplier's product is the supplier's job, under your contract.
Common mistakes
- Answering each state from scratch. It guarantees inconsistency.
- Claiming continuous monitoring without proof. Show ongoing detection across the systems in scope, or take the periodic route.
- Leaving application dependencies out of "vulnerability management". An infrastructure-only scan answer invites the follow-up about the software inside your own applications.
- Promising timelines you do not meet. If the log contradicts the standard, the finding writes itself.
- Exceptions without expiry. Every exception needs a reason, an approver and an end date.
- Letting engineering and compliance write separate answers. One owner per control, one canonical answer, one approver.
- Forgetting the board report. 314.4(i) requires an annual written report. Examiners ask for it early.
FAQ
Does the FTC Safeguards Rule apply to money transmitters?
For most non-bank money transmitters, yes. The rule covers financial institutions under FTC jurisdiction that are not subject to another GLBA regulator, and 16 CFR 314.2 names wire transferors and check cashers among them. Check with counsel if you are owned by a bank or otherwise supervised by a federal banking agency.
How often does the Safeguards Rule require vulnerability scans?
Without effective continuous monitoring, 314.4(d)(2)(ii) requires vulnerability assessments at least every six months, after material changes to operations or business arrangements, and when circumstances may materially affect your program. 314.4(d)(2)(i) adds an annual penetration test.
What does continuous monitoring mean under 314.4(d)(2)?
The rule does not define it. It contrasts it with periodic testing and describes systems that detect, on an ongoing basis, changes in information systems that may create vulnerabilities. If you claim it, describe the scope, frequency and detection, and show evidence for the exam period.
Do state examiners share my answers with other states?
They can. The MTMA's Section 4.04 authorizes adopting states to cooperate and share information through CSBS and the MTRA, and Section 4.03 lets a state accept another state's examination report. Assume your answers will be compared.
What is the CSBS Nonbank Ransomware Self-Assessment Tool?
It is a self-assessment published by CSBS, developed with the Bankers Electronic Crimes Taskforce and the US Secret Service, now at version 2.0. CSBS says it gives management and the board an overview of ransomware preparedness and may help regulators who review your practices.
How do I keep answers consistent across states?
Build the library on controls mapped to 314.4, write one canonical answer per control, version it, and log the exact text and evidence sent to each state. A new questionnaire becomes a mapping exercise.
Does New York's Part 500 apply to a money transmitter?
Part 500 covers anyone operating under a licence or similar authorization under New York's Banking Law, Insurance Law or Financial Services Law. Confirm with counsel how your New York licence is issued; if you are covered, map your answers to 500.5, 500.11 and 500.17 as well.
Can an AI tool answer the exam questionnaire for me?
It can draft. A person must check every answer against evidence and approve it, and only you submit to the examiner. In Safeguard, the assistant and MCP clients can prepare work but cannot approve or accept anything.
What if my sponsor bank asks for a stricter patch timeline than my standard?
Consider adopting the stricter timeline everywhere. One standard is easier to evidence than two.
An examiner's vulnerability questions are easiest to answer when there are few open findings to explain, and the fastest way to get there is to close the gap between a published fix and your next release. The block below describes how Safeguard closes that gap for the open source dependencies and container images you build, which is the part of the 314.4(d)(2) answer that most often carries old, unexplained findings.
Fix it without waiting for upstream
Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.
1. Autonomous remediation: pull requests, not tickets
When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.
2. Gold Open Source: the safe version in seconds, free
gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.
3. Gold Registry: start from components that are already fixed
Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.
When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | Safeguard policies and gates in CI |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.
See how Safeguard would help
The first demo shows Claude connected to the Safeguard MCP server with OAuth, and how you choose which tools Claude can use. For exam preparation, the same connection lets an assistant read your programme and prepare drafts, such as a first pass at a questionnaire answer from your vulnerability records, while every approval stays with a person in the app.
Click through it at your own pace, or open it full screen.
The second demo is a real desktop app session: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. That is the remediation half of a vulnerability answer: a dated fix with a human approval on every change, which is the kind of record an examiner samples.
Click through it at your own pace, or open it full screen.
Quick check
Under 16 CFR 314.4(d)(2), what must you do if you do not have effective continuous monitoring?
Run a penetration test of your information systems every year, scoped on the risks in your risk assessment, and run vulnerability assessments at least every six months, after material changes to operations or business arrangements, and whenever circumstances may materially affect your information security program.
Why should the answer library be organised by control rather than by state questionnaire?
Because the controls behind the questions are stable and the FTC Safeguards Rule gives the same control spine in every state, while questionnaires change wording from state to state and year to year. With one canonical answer per control, a new questionnaire is a mapping exercise, and the answers stay consistent when states compare them.
Sources
- eCFR: 16 CFR Part 314, Standards for Safeguarding Customer Information
- CSBS: Money Transmission Modernization Act (MTMA)
- CSBS: Money Transmission Modernization Act, model law text (PDF)
- CSBS: Networked Supervision
- CSBS: One Company, One Exam: Driving Forward Change
- CSBS: Advancing State Laws for Networked Supervision
- CSBS: Ransomware Self-Assessment Tool, including the Nonbank R-SAT
- New York DFS: 23 NYCRR Part 500, Second Amendment text (unofficial version published by the department)
- Federal Register: Interagency Guidance on Third-Party Relationships: Risk Management (9 June 2023)
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- PCI Security Standards Council: Document Library
- Safeguard docs: Compliance
- Safeguard docs: GLBA framework
- Safeguard docs: Vulnerabilities
- Safeguard docs: Third Party Risk Manager
- Safeguard docs: Approvals
- Safeguard docs: Requests and approvals
- Safeguard docs: Trust Center setup
Download Safeguard at safeguard.sh/download, and read the product documentation at docs.safeguard.sh.
Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.
