PBOC and NFRA rules: assess your mobile banking app before every release.
The PBOC standard JR/T 0092 and Notice 237 require annual external assessments and real-name filing for mobile financial apps, and the PBOC standard JR/T 0171 sets encryption, masking and annual testing duties for personal financial information. PBOC's 2025 data security measures add an inventory of APIs and security testing before changes go live, and NFRA's 2024 measures say identity authentication data must never be stored, transmitted or displayed in plain text. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the store build and the APIs it calls, including security testing before an API change goes live
- Checks tamper resistance, root and emulator detection, and what the app leaves on the device
- Tests login, one-time codes and transaction verification with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Who it applies to
- Banks and other financial institutions in mainland China, and the mobile finance apps they operate
- Legal basis
- PBOC financial industry standards JR/T 0092-2019, JR/T 0068-2020 and JR/T 0171-2020, plus the PBOC and NFRA data security measures
- Key date
- PBOC data security measures in force from 30 June 2025; the amended Cybersecurity Law in force from 1 January 2026
- Focus
- Mobile app security, annual external assessment, financial app filing, personal financial information protection and API security testing
How China's mobile finance rules took shape
The PBOC standards set the app baseline, the data security measures add the API and data duties, and MIIT and NIFA run the filing systems. The dates below are for the texts cited on this page.
- 27 September 2019
JR/T 0092-2019 and Notice 237
PBOC issues the Mobile financial client application software security management specification together with Notice 银发〔2019〕237号. It sets security and management requirements for mobile finance apps, requires an external assessment at least once a year, and starts real-name filing through the National Internet Finance Association of China. (Chinese text)
- 13 February 2020
JR/T 0171-2020
PBOC issues the Personal financial information protection technical specification together with Notice 银发〔2020〕45号. It classifies personal financial information into C3, C2 and C1 categories and sets lifecycle requirements, including an annual security check or assessment of the systems that handle it. (Chinese text)
- 21 July 2023
MIIT app filing
The Ministry of Industry and Information Technology requires app providers that run internet information services in mainland China to file through their network access provider or app store. Existing apps had to file by 31 March 2024, and new apps must file before they start service. (Chinese text)
- 27 December 2024
NFRA data security measures
NFRA issues the Measures for Data Security Management of Banking and Insurance Institutions (金规〔2024〕24号), in force on publication. They require security testing before systems go live, isolation of test environments, and no plain text storage, transmission or display of personal identity authentication data. (Chinese text)
- 1 May 2025
PBOC data security measures
PBOC publishes Order No. 3 [2025], the Measures for Data Security Management in the PBOC Business Domain, in force from 30 June 2025. They require an inventory of front-end gateways and APIs, security testing before an API change goes live, encryption of high sensitivity data, and annual risk assessments for important data. (Chinese text)
- 28 October 2025
Cybersecurity Law amended
The Standing Committee of the National People's Congress adopts amendments to the Cybersecurity Law, in force from 1 January 2026. They add provisions on the safe development of artificial intelligence, raise penalties, and align the law with the Data Security Law and the Personal Information Protection Law.
- 3 July 2026
Draft financial industry cyber rules
PBOC, NFRA, the CSRC and SAFE publish the draft Financial Industry Network Security Management Measures for public comment until 3 August 2026. The draft would set classified protection duties, supply chain security and incident handling across financial institutions. Proposed only, not yet in force. (Chinese text)
- Every year
Assessment and filing cycle
For funds transaction and information collection apps, the external assessment and the NIFA filing have a one year cycle, and systems that collect, store, transmit or use personal financial information need a security check or assessment at least once a year.
The PBOC and NFRA rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. Texts published only in Chinese are summarised and marked (Chinese text).
- PBOC Notice 银发〔2019〕237号; JR/T 0092-2019, clauses 4 to 6 (Chinese text)
Meet the mobile app security baseline
What the text says
The standard applies to mobile financial client application software and covers security requirements and management requirements across design, development, maintenance and release. It sorts apps into funds transaction, information collection and information query categories. Funds transaction apps must meet all technical and management requirements, and information collection apps must focus on information protection. Each requirement is marked basic or enhanced: basic requirements are the minimum protections, and enhanced requirements are recommended. Notice 237 requires an external assessment for funds transaction apps from the funds security and information protection aspects, and for information collection apps from the information protection aspect, at least once a year, with the report kept on file.
Source:PBOC Notice 银发〔2019〕237号; JR/T 0092-2019, clauses 4 to 6 (Chinese text)
What it means for your mobile app
The clause list reads like a test plan for the build your customers download, from signing and tamper checks to input protection, storage and data clearing.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly with no source code needed. An AI-agent pentest tests the app and its APIs behind login, with a working exploit you can replay for each AI-agent finding, and Mobile Shielding Scan tests the protections at runtime.
What stays with you
The external assessment with an accredited certification and testing body, and the annual assessment schedule.
- PBOC Notice 银发〔2019〕237号; NIFA mobile financial client app filing measures and filing notices (Chinese text)
File the app with NIFA and keep the assessment current
What the text says
Notice 237 asks financial institutions to take part in real-name filing of mobile finance apps through the National Internet Finance Association of China (NIFA), which runs the filing system at finapp.nifa.org.cn. Filing requires an external assessment report for funds transaction and information collection apps, a filing is valid for one year, and a major change or a filing not updated within a year triggers a new external assessment. NIFA checks annual assessments and can suspend or cancel a filing, and it has advised app stores to be cautious about distributing unfiled finance apps. NIFA reported that by the end of 2025, 844 institutions had filed 2,773 mobile finance apps.
What it means for your mobile app
Filing and the annual assessment are operational duties that repeat every year, and the assessment is evidence that a third party reviews, not a self declaration.
How Ostorlab helps
Ostorlab scans produce dated evidence per release that your team can attach to the external assessment and the filing update, and scans are repeatable when a new version needs a fresh assessment.
What stays with you
The filing itself, the relationship with the certification and testing body, and the decision on what counts as a major change.
- MIIT Notice 工信部信管〔2023〕105号; Cybersecurity Law as amended on 28 October 2025 (Chinese text)
File the app with MIIT before it goes live
What the text says
The Ministry of Industry and Information Technology requires app providers that run internet information services in mainland China to file through their network access provider or app distribution platform. New apps must file before they start service, and existing apps had to file between September 2023 and 31 March 2024. Telecom administrations check filings on an ongoing basis, and providers that do not file may not run app internet information services. The 2025 amendment to the Cybersecurity Law also puts security management duties on application download service providers, with penalties that can include suspension of business or closure of the app.
Source:MIIT Notice 工信部信管〔2023〕105号; Cybersecurity Law as amended on 28 October 2025 (Chinese text)
What it means for your mobile app
A bank app is both a financial app for PBOC and NIFA purposes and an app providing internet information services for MIIT purposes. The two filing tracks are separate.
How Ostorlab helps
Ostorlab does not file apps. It gives you dated security evidence that supports your filing records and the security statements behind them, release after release.
What stays with you
The filings themselves, the store listings and the answers to the telecom administration.
- JR/T 0068-2020, 6.2.1; JR/T 0092-2019, 5.3.3 and 5.3.4 (Chinese text)
Secure the client program itself
What the text says
Client programs must avoid risks in system components, third party components and SDKs, with selection testing where necessary. They must carry a clear application identifier and version, be signed by the app owner to show origin and publisher, and check their authenticity and integrity at startup and update to resist tampering, replacement or hijacking. They must use code obfuscation and packing, protect themselves from code injection, privilege escalation and process access, protect payment sensitive input and memory, refuse to store payment sensitive information locally, mask passwords, log out after a period without activity, apply least privilege permissions, and clear non essential data when they exit. The app must also detect its own running environment, including unauthorised administrator rights and emulators or virtual machines, feed that to the backend, and warn the user or refuse the transaction when the environment is risky.
Source:JR/T 0068-2020, 6.2.1; JR/T 0092-2019, 5.3.3 and 5.3.4 (Chinese text)
What it means for your mobile app
Every one of these behaviours can be tested on the released build, not only reviewed in the source code.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and instrumented environments, attempts to bypass root, emulator and tamper detection and TLS pinning, and reports what the app does when a protection fails. Mobile SAST covers the code and SDK side.
What stays with you
Choosing and configuring your shielding product, the release signing process, and the risk policy for compromised devices.
- JR/T 0171-2020, 6.1 and 7.4.2 (Chinese text)
Protect personal financial information by category
What the text says
The specification classifies personal financial information into C3, C2 and C1 by the harm that unauthorised viewing or change would cause. C3 covers user authentication information, including bank card track data, card verification codes, card passwords and payment transaction passwords, and personal biometric information used for user authentication. C3 information must be encrypted at rest, and C2 and C3 information must use encrypted channels or data encryption when it travels over public networks. Client apps and personal devices must not store payment sensitive information or biometric samples and templates, and may keep only the basic elements needed for the current transaction, cleared right after it. Displayed personal financial information must be masked, and development and test environments must be isolated from production and must not use real personal financial information. Systems that collect, store, transmit or use personal financial information need a security check or assessment at least once a year, including information security assessment, vulnerability scanning and penetration testing, with a new assessment when a major change or a new high risk threat appears.
What it means for your mobile app
The app bundle, its caches, logs, screenshots and the test process are all in scope, and the annual assessment expects real testing, not a checklist.
How Ostorlab helps
Ostorlab looks for payment data, tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and rates and tracks each finding. Every scan is dated, so annual assessment evidence accumulates release after release.
What stays with you
Categorising your data, the encryption design, and the impact assessment that the specification requires for sharing, transfer or entrusted processing.
- JR/T 0068-2020, 6.2.3 and 6.4.2; JR/T 0092-2019, 5.1.1 and 5.5.6.3 (Chinese text)
Verify high risk transactions and end sessions cleanly
What the text says
For high risk transactions, the internet banking standard requires a combination of at least two of three factor classes: something the customer knows, something only the customer holds such as an authenticated certificate, electronic signature or one time password, and a biometric factor. The factors must be independent, and damage to or leak of one must not damage another. One time passwords must have the shortest practical validity. After no more than 10 consecutive authentication failures, the login or transaction permission must be locked in a short time, with a documented way to unlock. Changing the reserved mobile number used for transaction notices and one time codes requires a counter visit or two factor authentication against the original number. Communication between client and server uses mutual authentication with keys or certificates, and the client validates the server certificate. Client programs log out automatically after inactivity, and a normal logout tells the server to end the session.
Source:JR/T 0068-2020, 6.2.3 and 6.4.2; JR/T 0092-2019, 5.1.1 and 5.5.6.3 (Chinese text)
What it means for your mobile app
Factor independence, one time code lifetime, lockout thresholds and server side session invalidation are all testable with your own test accounts.
How Ostorlab helps
Authenticated testing completes SMS, email or TOTP one time codes with your test accounts, tests MFA enforcement, step up flows and lockout behaviour, and checks token refresh, timeouts and session invalidation through the API calls behind them.
What stays with you
Factor choice and channel design, the unlock process, and the customer notification channels.
- PBOC Order No. 3 [2025], Articles 35 and 36; NFRA 金规〔2024〕24号, Articles 48 and 53 (Chinese text)
Test APIs before a change goes live
What the text says
PBOC requires a dynamic inventory of the front-end gateways and application programming interfaces that provide business data, and security testing before a gateway or API change goes into production, with immediate remediation of any risk found. High sensitivity items must in principle be encrypted when transmitted to other processors, other data centres or the internet, and dedicated lines or VPNs should be preferred. NFRA requires data interactions with external parties to go through a centrally managed external platform or APIs, designed, developed, served and operated under central security management on a need to know and least privilege basis. Systems must pass security testing before going live, and test environments must be separated from production with no unmasked sensitive data.
Source:PBOC Order No. 3 [2025], Articles 35 and 36; NFRA 金规〔2024〕24号, Articles 48 and 53 (Chinese text)
What it means for your mobile app
Every release that touches an API is a change that needs testing before production, and the API inventory is part of the evidence.
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 architecture, network encryption choices and production monitoring.
- PBOC Order No. 3 [2025], Articles 16, 17, 20 and 33; NFRA 金规〔2024〕24号, Articles 43, 45 and 46 (Chinese text)
Keep sensitive data off devices and out of plain text
What the text says
High sensitivity data items must in principle not be stored on terminal devices and removable media, and when business needs require it those scenarios are centrally listed and controlled. Data used for identity verification should in principle be verified rather than exported, and high sensitivity items should be masked when displayed. High sensitivity items must in principle not travel by email, instant messaging, online file storage or removable media. NFRA is specific about authentication data: personal identity authentication data must not be stored, transmitted or displayed in plain text, and sensitive and higher data must be deleted or destroyed beyond recovery when its retention period ends, including on terminals and media. Operation logs for core data are kept at least three years, and for important and sensitive data at least one year, and access behaviour is audited at least every six months.
What it means for your mobile app
Plain text identity data is an explicit violation, not a hardening preference, and it is one of the easiest things a mobile test can prove.
How Ostorlab helps
Ostorlab finds identity data and credentials in storage, caches, logs, screenshots and app packages, validates which secrets work, and shows how the app and its SDKs exchange data with backends over the network.
What stays with you
Data classification, device management policies, and the deletion or destruction process.
- GB/T 22239-2019; PBOC Order No. 3 [2025], Article 32; NFRA 金规〔2024〕24号, Article 41 (Chinese text)
Meet classified protection duties
What the text says
Network security classified protection is the base regime for information systems in China. GB/T 22239-2019 sets the general security requirements for levels 1 to 4 and the extended requirements for cloud, mobile internet, internet of things and industrial control systems. PBOC requires systems that store important data to meet level 3 classified protection and systems that store core data to meet level 4 classified protection or critical information infrastructure protection. NFRA requires banks to bring data into classified protection, divide logical security domains by data level, and protect rooms and networks that hold or transmit sensitive and higher data. JR/T 0068 points internet banking systems to the financial sector MLPS implementation guidance, JR/T 0071, for technical and management requirements, including the mobile internet extension.
Source:GB/T 22239-2019; PBOC Order No. 3 [2025], Article 32; NFRA 金规〔2024〕24号, Article 41 (Chinese text)
What it means for your mobile app
The level of the system behind the app sets the protection baseline, and the mobile app is part of that system's boundary.
How Ostorlab helps
Ostorlab tests controls in the app and its APIs and gives you dated findings and retests for the technical items of the classified protection assessment, so known app level issues do not surprise the formal evaluation.
What stays with you
Grading and filing of systems, the formal MLPS evaluation with a licensed assessment body, and the physical and network controls.
- NFRA IT outsourcing measures 银保监办发〔2021〕141号, Articles 5, 11, 17, 21, 32, 34 to 36 and 38; NFRA operational risk measures, Order No. 5 of 2023, Articles 29 to 31 (Chinese text)
Manage outsourcing and operational risk
What the text says
NFRA's IT outsourcing measures say the institution cannot outsource IT management responsibility or cybersecurity responsibility. IT strategy management, IT risk management, IT internal audit and other core competitiveness functions must not be outsourced. Important outsourcing needs due diligence before the contract, contract terms that cover compliance, service continuity, audit rights, security and confidentiality and incident reporting, and security scanning of development deliverables including source code. Network and information security measures include need to know and least privilege access for provider staff, strict control of remote maintenance, continuous monitoring for sensitive data leaks, and regular security assessments of the outsourcing activity. Institutions must check important off site outsourcing on site at least every three years, run a full outsourcing risk management assessment at least once a year, and audit important outsourcing at least every three years. Major events, including leaks of customer personal information, must be reported, and if no other rule sets a deadline, within 24 hours. The operational risk measures require systems for network security, data security and outsourcing risk management, connected to business continuity.
What it means for your mobile app
Every SDK, testing vendor and cloud service your app depends on sits inside this framework, and testing evidence is how you monitor the security duty.
How Ostorlab helps
Ostorlab tests the app and the components inside it, lists the SDKs and native libraries in each release with their versions, and maps them to known vulnerabilities with closure tracked across releases, so third party components have evidence of their own.
What stays with you
Due diligence, contracts, access control for provider staff, on site checks, annual assessments and incident reporting.
Summary of public PBOC, NFRA, MIIT, NIFA and NPC texts, checked on 27 September 2026. Texts published only in Chinese are summarised and marked (Chinese text). This page is not legal advice.
Chinese rules, control by control
The controls the PBOC, NFRA and MIIT texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Mobile app security baseline and annual external assessmentJR/T 0092-2019; Notice 237 | AI-agent pentest of the store build and its APIs, behind login, with Mobile SAST on the binary. Details | A working exploit you can replay for each AI-agent finding, and scan results per build |
| App signing, integrity and tamper resistanceJR/T 0092-2019 5.3.3; JR/T 0068-2020 6.2.1.1 | Modifies the binary, injects debuggers and hooks, and attempts to bypass integrity and pinning protections. Details | Evidence of which protections held and which were bypassed |
| Unauthorised administrator rights and emulator detectionJR/T 0092-2019 5.3.4 | Runs the app in rooted and emulated environments and attempts to bypass the detection. Details | Hardening score, and bypass evidence for each protection that failed |
| No payment sensitive data or biometric templates on the deviceJR/T 0092-2019 5.5.4.1; JR/T 0171-2020 6.1.3 | Looks for payment data, tokens and personal data in storage, caches, logs and screenshots. Details | File system evidence showing what was written, where and when |
| Masking of displayed personal financial informationJR/T 0171-2020 6.1.4.1 | Runs the app, captures the screens it shows and the API responses behind them, and checks what personal data appears in clear. Details | Screens and screenshots that show which data fields were exposed |
| Authentication factors, lockout and reserved number changesJR/T 0068-2020 6.4.2.1; JR/T 0092-2019 5.1.1 | Logs in with one time codes and tests MFA enforcement, step up flows, lockout and number change rules. Details | Findings on login, lockout and number change flows, with reproduction steps |
| Session end, inactivity logout and token handlingJR/T 0068-2020 6.2.1.1; JR/T 0092-2019 5.5.6.3 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| API and gateway inventory, and testing before go livePBOC Order No. 3 [2025], Articles 35 and 36 | 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, with the release it belongs to |
| SDK and third party component recordsJR/T 0092-2019 6.4; JR/T 0068-2020 6.2.1.1 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Component identity, version and location in the app bundle, per release |
| Classified protection and remediation trackingGB/T 22239-2019; PBOC Order No. 3 [2025], Article 32 | 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 |
Ostorlab tests controls in the app and its APIs. MIIT and NIFA filings, external assessments by accredited bodies, formal MLPS evaluation, SOC monitoring, incident reporting, outsourcing management and governance stay with your teams.
PBOC and NFRA controls to test in your mobile app
A practical list for security and compliance teams, based on the PBOC standards, the two data security measures, the MIIT filing notice and the NFRA outsourcing rules.
Annual external assessment
Put the app in the annual external assessment cycle, keep the report on file, and refresh it after major changes or when the filing year turns.
Financial app filing
Keep the NIFA filing and its security material current, and check the MIIT filing behind each store listing and release.
Self protection
Test signing, integrity checks, obfuscation, process protection and secure input on the build your customers download.
Environment detection
Run the app on rooted and emulated devices and check that risky environments are detected, reported to the backend and handled.
Data on the device
Look for payment sensitive information, biometric templates, tokens and personal data in storage, caches, logs and screenshots, and check that they are cleared after the transaction.
Authentication and sessions
Verify factor independence, one time code lifetime, lockout after consecutive failures, reserved number changes and server side session invalidation.
APIs before production
Keep the gateway and API inventory current and run security testing on every change before it reaches production.
Third parties and records
Keep SDK and component records per release, scan provider deliverables, and keep the evidence for the annual assessments and audits.
A suggested list, not a PBOC, NFRA or MIIT 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
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.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
- 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.
- 移动金融客户端应用软件安全管理规范 (Mobile financial client application software security management specification), JR/T 0092-2019PBOC, published and effective 27 September 2019, replacing JR/T 0092-2012. Issued with Notice 银发〔2019〕237号, which requires an external assessment at least once a year and real-name filing through NIFA. Chinese text
- 网上银行系统信息安全通用规范 (General specification of information security for internet banking system), JR/T 0068-2020PBOC, published and effective 5 February 2020, replacing JR/T 0068-2012. Client program security, environment detection, communication security, authentication and transaction rules, and classified protection. Chinese text
- 个人金融信息保护技术规范 (Personal financial information protection technical specification), JR/T 0171-2020PBOC, published and effective 13 February 2020, issued with Notice 银发〔2020〕45号. C3, C2 and C1 categories, lifecycle requirements, and an annual security check or assessment. Chinese text
- 中国人民银行业务领域数据安全管理办法 (Measures for Data Security Management in the PBOC Business Domain), PBOC Order No. 3 [2025]PBOC, adopted 2 April 2025, published 1 May 2025, in force from 30 June 2025. Classification and sensitivity, storage and transmission protection, API inventory and testing, risk assessment, audit and incident duties. Chinese text
- 银行保险机构数据安全管理办法 (Measures for Data Security Management of Banking and Insurance Institutions), 金规〔2024〕24号NFRA, issued 27 December 2024, in force on publication, replacing the 2022 measure 银保监办发〔2022〕118号. Data classification, lifecycle controls, security testing before go live, plain text rules and incident reporting. Chinese text
- 银行保险机构信息科技外包风险监管办法 (Measures for the Regulation of IT Outsourcing Risk of Banking and Insurance Institutions), 银保监办发〔2021〕141号NFRA, issued 30 December 2021, in force on publication. Outsourcing governance, due diligence, contract terms, security assessments, on site checks, annual review and audit duties, and major event reporting. Chinese text
- 信息安全技术 网络安全等级保护基本要求 (Information security technology: Baseline for classified protection of cybersecurity), GB/T 22239-2019SAMR and SAC, published 10 May 2019, in force from 1 December 2019. The MLPS 2.0 baseline, with general requirements for levels 1 to 4 and a mobile internet extension. Chinese text
- 中华人民共和国网络安全法 (Cybersecurity Law), as amended on 28 October 2025NPC Standing Committee, amendment adopted 28 October 2025, in force from 1 January 2026. Adds artificial intelligence provisions, raises penalties, and aligns with the Data Security Law (adopted 10 June 2021, in force 1 September 2021) and the Personal Information Protection Law (adopted 20 August 2021, in force 1 November 2021). Chinese text
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.
Assess your mobile banking app the way PBOC and NFRA describe it
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.