# Did not meet TRUSTED criteria This build did not satisfy all of CITT's published criteria for the TRUSTED mark. The full criteria and this app's results are shown below. ## Trust Pillars - **Secure by Design**: Not met. Did not meet one criterion in this area. - **Data Minimization**: Not met. Did not meet one criterion in this area. - **Manifest Mismatch**: Critical issue. Has a high-severity open item in this area, detailed below. - **User Control**: Strong. Strong result in this area. - **Truly Local**: Not applicable. Does not apply to this app. - **Child-Safe**: Not applicable. Does not apply to this app. --- # Security & Privacy Scorecard ## Interbank APP ## What This Means for You Build 334 processes core banking transactions on Interbank's own servers while bundling six analytics and session-recording SDKs that are initialized at launch. The Play Store Data Safety label for this app declared "No data shared with third parties" as of August 2026. ## Recommendation: Use With Caution Build 334 functions as a capable mobile banking client for existing Interbank customers. Core financial account data and transactions are handled on Interbank-controlled infrastructure with HTTPS enforced across those connections. The principal concerns in this build are a payment component that ships with network validation disabled and a debug build configuration, and six analytics, attribution, and session-recording SDKs initialized at launch without an observed consent mechanism, which is inconsistent with the Play Store Data Safety declaration. **Best For:** Existing Interbank customers who need mobile access to account management, transfers, and bill payment in Peru. ## Method and Limitations Static analysis only. CITT reviewed the code of this build without running the app, so runtime behavior was not observed. The findings below describe the analyzed build and may not reflect server-side controls or later versions. CITT makes no determination about compliance with any law or platform policy; it reports what the artifacts contain and cites the published guidance so a reader can compare. ## Key Findings **Data Security:** 1 finding (1 low) **Network Security:** 1 finding (1 high) **Code Safety:** 8 findings (1 high, 5 medium, 2 low) **Privacy:** 1 finding (1 high) ## Privacy Concerns ### What Leaves the Device - Device identifiers and install attribution signals: the AppsFlyer SDK is bundled and initialized at launch without an observed consent gate; runtime data egress was not confirmed but is consistent with AppsFlyer's standard configuration - Behavioral and session data: the Adobe MobileCore SDK is initialized with no observed consent check and configured to reach Adobe Experience Cloud services - Screen-recording sessions: the Microsoft Clarity SDK is present in the build and may share recorded session data with Microsoft servers; this was not confirmed at runtime - Geofencing and proximity data: the IBM Acoustic Mobile Push SDK is bundled and may share location-derived data with IBM; runtime transmission was not observed - Device fingerprint and risk signals: the ThreatMetrix TrustDefender (LexisNexis) SDK is present and may share device intelligence with LexisNexis; this was not confirmed at runtime - Call metadata and installed application inventory: the IO SRO Collector SDK is initialized and may share this data with an unidentified vendor; runtime transmission was not confirmed ### What Stays on the Device - Text recognition, barcode scanning, and face detection: handled by Google ML Kit, which processes these tasks on the device with no evidenced data egress - Biometric authentication data: managed by the device's hardware-backed secure storage and not transmitted off the device ### Third-Party Data Sharing **Third parties that may receive data from the app:** - AppsFlyer - install attribution and behavioral analytics - Adobe Experience Cloud - behavioral analytics and in-app messaging - Microsoft Clarity - session recording - IBM Acoustic - location-based push notifications - ThreatMetrix TrustDefender (LexisNexis) - device fingerprinting for fraud detection - IO SRO Collector - device intelligence (vendor not identified in the analyzed build) - Google Firebase - crash reporting, push notifications, remote configuration - Dynatrace - application performance monitoring ## Understanding the Scores **Security:** 65/100 **Privacy:** 64/100 ### Security Breakdown - **Data Security:** 73/100. Core banking data is processed on Interbank's infrastructure. A bundled cloud configuration file in the build contains identity pool identifiers that could support account enumeration attempts against the associated cloud service; this scenario was not tested at runtime. - **Network Security:** 60/100. Interbank API connections enforce HTTPS without cleartext exceptions. The analyzed build's IziPay payment SDK component configures its network client to accept any server identity, creating a potential gap for payment-specific traffic when the device is on an untrusted network; this was not confirmed at runtime. - **Code Safety:** 73/100. The build includes hardware-backed biometric security, native integrity checks, and runtime process monitoring that polls at short intervals. Several development and debug components are present in the production build, expanding the accessible surface beyond what is required for banking functionality. ### Privacy Breakdown - **Data Collection:** 71/100. The build bundles multiple analytics, attribution, and session-recording SDKs initialized at launch. Google ML Kit processes recognition tasks on-device with no evidenced data leaving the device. - **Data Sharing:** 75/100. Core banking transactions and account data are handled on Interbank-owned infrastructure. Six third-party SDKs may share behavioral, device, and session data with their respective vendors, as detailed in the Privacy Concerns section above. - **User Control:** 76/100. The build supports biometric authentication and provides an option to hide account balances. Data deletion can be requested per the Play Store listing. ## Positive Security Features - HTTPS is enforced across Interbank's network connections; cleartext traffic exceptions are not present in the build - App data backup is disabled, blocking backup-based data extraction - Biometric authentication is bound to hardware-backed secure storage on the device - Fifteen native library security checks resist hooking at the application layer - Runtime integrity monitoring polls at short intervals and terminates the process on failure - Core financial data (balances, transactions, card details) is processed on Interbank-owned infrastructure and not shared with analytics platforms - Google ML Kit processes text recognition, barcode scanning, and face detection on the device with no evidenced data egress - No advertising or ad-auction SDK is present in the build ## Areas for Improvement ### Disclosure observations Observations about disclosure, each stated against the published guidance so a reader can compare: 1. **Play Store Data Safety declaration** The Play Store Data Safety section for this app, as retrieved on 2026-08-11, declares "No data shared with third parties." The analyzed build (version 23.1) initializes AppsFlyer, Adobe MobileCore, Microsoft Clarity, IBM Acoustic, ThreatMetrix TrustDefender, and IO SRO Collector at launch. Whether each SDK's data flows constitute "sharing" within Google Play's Data Safety definitions could not be determined from the binary alone. Google Play's Data Safety policy requires developers to declare data shared with third parties used for purposes beyond servicing the transaction; readers can compare that published requirement against the declared label. ### Security Enhancements 1. **Payment SDK build configuration** The bundled IziPay payment SDK ships as a debug build variant with network validation disabled and a sandbox gateway configured. Replacing it with a production-signed release variant that restores network protections would close the gap for payment-flow traffic. 2. **Biometric component access control** The biometric identity component in the build is accessible to other apps on the device without a permission requirement. Adding an explicit permission restriction would limit which applications can invoke it and reduce the risk of cross-app biometric data access. 3. **External link input handling** The build accepts incoming URI parameters for payment and transfer flows without verifying the source. Checking the calling context before processing payment-related parameters would reduce the risk of misdirected transfers or payments. 4. **Development components in production** The production build includes a diagnostics SDK (Adobe Experience Platform Assurance), a UI preview component, and a debug build variant of the payment SDK. Excluding development-only libraries from release builds is standard practice and reduces the accessible surface. ## Technical Context **App Type:** Mobile banking - high-sensitivity financial application **Classes Analyzed:** 3,200 **Third-Party Services:** 20 **Context Tags:** financial, sensitive_data, location, camera --- ## About This Analysis This security analysis was conducted by CITT (Can I Trust That), an independent security analysis service. The analysis is static code review of Android applications, intended to help people make informed decisions about app security and privacy. ### App Details **Developer:** Banco Internacional del Peru **Version:** 23.1 (Build 1843) **Analysis Date:** 2026-08-13 **Package:** pe.com.interbank.mobilebanking ### Analysis Limitations - Static analysis only (code review without running the app) - Based on APK version 23.1 analyzed on 2026-08-13 - May not reflect server-side security controls - Cannot detect all runtime behaviors