FFIEC and NYDFS: test your mobile banking app before every launch and change.
US examiners expect penetration tests, vulnerability assessments and application security tests before launching or making significant changes to external-facing applications, and the FFIEC lists downloadable mobile applications among the applications institutions and customers use. In New York, 23 NYCRR Part 500 adds annual penetration testing, automated scans at a risk-based frequency and, since 1 November 2025, MFA for any individual accessing a covered entity's information systems. Ostorlab supports your testing obligations for the mobile app and the APIs behind it, on every release.
- Static and dynamic testing of the build you ship, from your CI/CD pipeline, with no source code needed
- Penetration testing by AI agents behind login, including one-time codes
- API tests for broken object and function level authorization, even with TLS pinning
- Risk ratings, tickets and retests, so every fix can be proven
- Who it applies to
- Banks and credit unions examined by the FFIEC member agencies, and NYDFS-regulated entities for Part 500
- Legal basis
- Gramm-Leach-Bliley Act section 501(b) and the Interagency Guidelines Establishing Information Security Standards
- Focus
- Application security testing, authentication, vulnerability management and third parties
- Reference
- FFIEC IT Examination Handbook and 23 NYCRR Part 500, as amended in November 2023
Recent changes to the US rules for bank apps
The FFIEC booklets and the GLBA security standards set a long-standing baseline. The dates below are for the newer texts cited on this page.
- 6 June 2023
Third-party guidance final
The Federal Reserve, FDIC and OCC issue joint guidance on third-party relationships, published in the Federal Register on 9 June 2023.
- 1 November 2023
NYDFS Part 500 amended
The second amendment to 23 NYCRR Part 500 takes effect, with compliance dates phased in over two years.
- 29 April 2024
Annual penetration testing
Penetration testing from inside and outside the information systems' boundaries at least annually, and timely, risk-based remediation, under the amended section 500.5.
- 1 May 2025
Automated scans
Automated scans of information systems, and manual review of systems not covered by them, at a frequency set by the risk assessment and promptly after material system changes.
- 1 November 2025
MFA for any individual
Section 500.12 requires MFA for any individual accessing any of a covered entity's information systems, unless the CISO approves equivalent or more secure controls in writing.
- 11 September 2026
New third-party guidance proposed
The agencies propose guidance that would rescind and replace the 2023 third-party guidance. Comments are due by 16 November 2026.
FFIEC, GLBA and NYDFS rules, applied to your mobile app
The FFIEC IT Examination Handbook tells examiners what to look for, the GLBA security standards set the baseline, and NYDFS Part 500 adds dated requirements in New York. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- FFIEC Information Security booklet, II.C.17
Test external-facing apps before launch and before significant changes
What the text says
Applications used by institutions and their customers include installable applications such as downloadable mobile applications. To verify the controls, management should perform appropriate tests, such as penetration tests, vulnerability assessments and application security tests, before launching or making significant changes to external-facing applications. Issues from the tests should be remediated before launch or before changes move into production, and third parties that develop applications should meet the same controls.
What it means for your mobile app
A new version of your mobile app is a change to an external-facing application. Testing belongs in the release process, and findings should be fixed before the build goes to the store, including in vendor-built apps.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, keeps authenticated sessions and captures traffic, stack traces and screenshots. SCA fingerprints statically compiled libraries that manifest-based scanners can miss.
What stays with you
The go-live decision, testing of server infrastructure, and the security requirements you set for vendors.
- FFIEC Information Security booklet, IV.A.1 and IV.A.2(b)
Set test frequency and independence by risk
What the text says
The institution's IT risk management process should determine the frequency of independent testing. Changes to or additions of systems and applications and changes in attacker techniques may increase it, with testing during development, before a new or modified system goes into production, and periodically in production. There are many types of penetration tests, including client-side and web application tests, and management should determine the level of independence required.
Source:FFIEC Information Security booklet, IV.A.1 and IV.A.2(b)
What it means for your mobile app
There is no fixed federal cadence. Frequent releases are a reason to test more often, and a mobile banking app needs both client-side and web application style testing of the APIs it calls.
How Ostorlab helps
Fast scans usually finish in 1 to 5 minutes and full scans in 15 to 45 minutes, so they fit every release. An AI-agent pentest goes deeper, typically in a few hours, with a working exploit you can replay for each AI-agent finding, for critical changes and your periodic deep tests.
What stays with you
The risk assessment that sets frequency and scope, and the decision on who counts as independent.
- Interagency Guidelines Establishing Information Security Standards, III.C
Regularly test the key controls
What the text says
Each institution shall regularly test the key controls, systems and procedures of its information security program. The frequency and nature of the tests should be determined by the institution's risk assessment, and tests should be conducted or reviewed by independent third parties or staff independent of those that develop or maintain the security programs. Access controls on customer information systems, including authentication, are among the measures to consider.
Source:Interagency Guidelines Establishing Information Security Standards, III.C
What it means for your mobile app
Login, authorization and data protection in the app and its APIs are key controls on customer information systems, so they belong in the test plan, with results reviewed by someone outside the team that builds them.
How Ostorlab helps
Your security or second-line team runs the tests and owns the results. Each finding comes with a risk rating, reproduction steps, request and response logs and screenshots, and retesting confirms whether the underlying issue is resolved.
What stays with you
The written information security program, the risk assessment and the yearly report to the board.
- FFIEC Development, Acquisition, and Maintenance booklet, IV.D and V.C.2
Build security testing into development
What the text says
Quality assurance tests such as fuzz testing and penetration testing, secure code reviews and source code security analyzers help identify security flaws for remediation. Vulnerability scanning in development environments finds vulnerabilities before users are exposed, and scanning continues after deployment. In DevSecOps, CI/CD pipelines use testing tools such as static and dynamic application security testing and software composition analysis, and stop further pipeline tasks when a build or test fails.
Source:FFIEC Development, Acquisition, and Maintenance booklet, IV.D and V.C.2
What it means for your mobile app
Automated security tests in the pipeline, with builds that fail on serious findings, are what examiners will look for, and they apply to the mobile app as much as to server code.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Scheduled runs of your pipeline keep a weekly cadence between releases. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Pipeline design, the rules for failing a build, and code reviews of your server-side code.
- FFIEC Development, Acquisition, and Maintenance booklet, IV.I.2; Architecture, Infrastructure, and Operations booklet, V.C.2(c)
Mitigate the common API risks
What the text says
Mitigation strategies for common API risks include object-level authorization checks, validating user authentication and considering MFA, avoiding excessive data exposure in responses, rate limiting, function-level authorization with access denied by default, protection against mass assignment and injection, and a current inventory of APIs. Public APIs should be tested to verify the adequacy of security controls before and after going public.
What it means for your mobile app
The APIs behind your app carry the money and the data. A customer who changes an account ID in a request should get an error, not someone else's balance.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
The API inventory, gateway and firewall configuration, and logging and monitoring of API activity.
- FFIEC Authentication and Access guidance (2021), Sections 3 to 5; Information Security booklet, II.C.16; 23 NYCRR 500.12
Layered security and MFA for digital banking
What the text says
When a risk assessment shows that single-factor authentication with layered security is inadequate, MFA or controls of equivalent strength, with other layered controls, can more effectively mitigate risk. Layered controls include MFA, user time-out and transaction limits, and the design and effectiveness of authentication controls should be assessed initially and periodically. For remote banking, controls may include application time-outs with mandatory re-authentication, out-of-band verification and device authentication. In New York, section 500.12 requires MFA for any individual accessing any of a covered entity's information systems.
What it means for your mobile app
Payments and account changes are high-risk transactions. The server should enforce the second factor, the step-up and the time-out, and you need evidence that it does. How section 500.12 applies to customer logins is a question for your compliance team.
How Ostorlab helps
Ostorlab logs in with your test accounts, completes SMS, email or TOTP one-time codes, and tests login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows.
What stays with you
The authentication risk assessment, the choice of factors, fraud monitoring and customer awareness.
- 23 NYCRR 500.5; FFIEC Architecture, Infrastructure, and Operations booklet, VI.B.3(a)
Penetration test yearly and scan by risk
What the text says
Covered entities must have written vulnerability management procedures that ensure, at a minimum, penetration testing of their information systems from both inside and outside the boundaries by a qualified internal or external party at least annually, and automated scans, with manual review of systems the scans do not cover, at a frequency determined by the risk assessment and promptly after any material system changes. Vulnerabilities must be remediated in a timely way, prioritised by risk. The FFIEC expects a method to track and report on the remediation progress of all identified vulnerabilities.
Source:23 NYCRR 500.5; FFIEC Architecture, Infrastructure, and Operations booklet, VI.B.3(a)
What it means for your mobile app
A mobile app release is often a material change to the systems customers reach. The yearly pentest covers the app and its APIs from outside, and automated scans fill the gap between tests.
How Ostorlab helps
Automated scans from your CI/CD pipeline on every build, including scheduled runs, and monitoring of store releases. The AI-agent pentest tests the app and its APIs behind login, and confirmed findings are tracked as tickets and retested after the fix.
What stays with you
Choosing a qualified party for the annual pentest, internal testing inside the boundaries, and your remediation deadlines.
- 23 NYCRR 500.8
Secure development and testing of external apps
What the text says
The cybersecurity program shall include written procedures, guidelines and standards for secure development practices for in-house developed applications, and procedures for evaluating, assessing or testing the security of externally developed applications used by the covered entity. The CISO, or a qualified designee, reviews and updates them at least annually.
Source:23 NYCRR 500.8
What it means for your mobile app
Your own app and the SDKs or white-label apps you buy both need a defined security testing step, and the procedure needs a yearly review.
How Ostorlab helps
Mobile SAST works on the compiled app, so it covers vendor-built apps and embedded SDKs you don't have the source for. SCA shows which third-party components each release ships, maps them to known vulnerabilities and tracks their closure from release to release.
What stays with you
The written procedures and the CISO's yearly review.
- Interagency Guidance on Third-Party Relationships (2023); FFIEC Information Security booklet, II.C.20; 23 NYCRR 500.11
Oversee third parties, including testing vendors
What the text says
The use of third parties does not diminish or remove a banking organization's responsibility to perform activities in a safe and sound manner and in compliance with applicable laws. Due diligence on information security can include assessing the third party's application security program, its software development life cycle and the results of its vulnerability and penetration tests, and controls such as multifactor authentication and encryption. Covered entities in New York must have third-party service provider security policies, including due diligence and contractual protections.
What it means for your mobile app
Vendors that build your app or run parts of it should show you their test results. A SaaS testing platform that receives your app binaries and test credentials is itself a vendor your process will review.
How Ostorlab helps
Ostorlab is SOC 2 Type II audited. On the Enterprise plan you can choose United States data residency or run scans on-premises, and with BYOK the AI runs on your own provider account with a spend cap per scan. SSO/SAML, role-based access control and audit logs are available as an add-on and included on Enterprise.
What stays with you
Your due diligence, the contract clauses and ongoing monitoring of each provider.
Summary of the FFIEC IT Examination Handbook, the FFIEC authentication guidance, the Interagency Guidelines Establishing Information Security Standards, the 2023 third-party guidance and 23 NYCRR Part 500, checked on 27 September 2026. The FFIEC booklets and interagency guidance are supervisory guidance; Part 500 applies to NYDFS-regulated entities. This page is not legal advice.
FFIEC and NYDFS, requirement by requirement
Where Ostorlab supports your mobile apps and their APIs, and the evidence you can keep for examiners and your yearly certification.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Tests before launching or changing external-facing appsFFIEC IS booklet, II.C.17 | Mobile SAST and DAST in the release pipeline, before the app reaches the store. Details | Scan results for each build |
| Client-side and web application penetration testsFFIEC IS booklet, IV.A.2(b) | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Annual penetration testing from outside the boundaries23 NYCRR 500.5(a)(1) | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | Risk rating and a replayable exploit for each AI-agent finding |
| Automated scans at a risk-based frequency and after material changes23 NYCRR 500.5(a)(2) | Automated scans from your CI/CD pipeline on every build, including scheduled runs, and monitoring of store releases. Details | Scan results per build and per store release |
| Timely remediation, prioritised by risk23 NYCRR 500.5(c); AIO booklet, VI.B.3(a) | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. | Ticket history and retest result for each finding |
| Code analysis and SCA in the CI/CD pipelineFFIEC DA&M booklet, IV.D and V.C.2 | Taint analysis across embedded SDKs, and dependency analysis of the compiled app. Details | Findings attributed to the SDK or library they come from |
| Security testing of externally developed applications23 NYCRR 500.8 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Object and function level authorization in APIsFFIEC DA&M booklet, IV.I.2 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| MFA, time-outs and re-authenticationFFIEC authentication guidance (2021); IS booklet, II.C.16; 23 NYCRR 500.12 | Logged-in testing with one-time codes, and checks of sessions, tokens, timeouts and MFA enforcement. Details | Findings on login, session and step-up flows with reproduction steps |
| Due diligence on your testing vendorThird-party guidance (2023); 23 NYCRR 500.11 | SOC 2 Type II audit, United States data residency, on-premises scanning and BYOK. Details | SOC 2 Type II report, on request from the Trust Center |
Ostorlab covers the mobile apps and the APIs behind them. Network and internal penetration testing, monitoring, incident response, business continuity, governance, the yearly NYDFS certification and board reporting stay with other tools and teams.
Put your mobile app into your US testing program
A practical sequence for security teams. Adapt it to your own risk assessment.
Inventory the app and its APIs
Record the app, the APIs it calls and the SDKs it embeds, and mark the transactions that count as high risk.
Take a baseline
Scan each customer-facing app once to see where you stand. A free scan from the store takes minutes.
Gate releases
Run static and dynamic tests on every build in CI/CD, and fix serious findings before the build goes to the store.
Cover logged-in flows
Add test accounts and one-time code delivery, so payments, payee changes and account settings are tested, not only the login screen.
Test the APIs
Check object and function level authorization on every account and payment API, including requests for other customers' data and repeated requests.
Plan the yearly pentest
Book the annual penetration test with a qualified party, and use AI-agent pentests for critical changes in between.
Track remediation
Send findings to Jira or ServiceNow with a rating, agree fix deadlines by severity, and retest every fix.
Keep the evidence
Keep scan results, tickets and retest outcomes for each release. NYDFS entities keep the records behind the yearly certification for five years.
A suggested sequence, not an FFIEC or NYDFS template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- FFIEC IT Examination Handbook: Information Security bookletFFIEC, revised on 9 September 2016, with a February 2026 update that removed references to reputational risk and set no new requirements. Application security, customer remote access and testing
- FFIEC IT Examination Handbook: Development, Acquisition, and Maintenance bookletFFIEC, issued in 2024 to replace the Development and Acquisition booklet of April 2004. Secure development, APIs, SBOM, testing and DevSecOps
- FFIEC IT Examination Handbook: Architecture, Infrastructure, and Operations bookletFFIEC, revised and renamed on 30 June 2021. APIs, vulnerability management and patch management
- Authentication and Access to Financial Institution Services and SystemsFFIEC guidance issued on 11 August 2021, replacing the 2005 and 2011 internet banking authentication guidance. Risk assessment, layered security and MFA. Copy published by the FDIC
- Interagency Guidelines Establishing Information Security StandardsStandards under GLBA section 501(b), in 12 CFR part 364, appendix B (FDIC), with parallel texts at 12 CFR part 30, appendix B (OCC) and 12 CFR part 208, appendix D-2 (Federal Reserve)
- Second Amendment to 23 NYCRR Part 500: Cybersecurity Requirements for Financial Services CompaniesNYDFS, effective 1 November 2023. The copy on the DFS website notes it is not the official version
- Amended Cybersecurity Regulation, Second Amendment, 23 NYCRR Part 500NYDFS training presentation of November 2023 with the phased compliance deadlines from 1 November 2023 to 1 November 2025
- Interagency Guidance on Third-Party Relationships: Risk ManagementFederal Reserve, FDIC and OCC, final as of 6 June 2023, 88 FR 37920. A proposal of 11 September 2026 would rescind and replace it
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app before the next release
Start with a free scan of your app from the store, or book a demo to run logged-in tests and an AI-agent pentest with our team.