The ScotiaConnect mobile app is built around approval and visibility, not origination. Treasurers, controllers and authorized signatories use it to approve batches, watch balances and action positive-pay decisions, with biometric unlock, device binding and jailbreak detection carrying the security model. This reference covers supported devices, feature boundary, offline behaviour and push-notification preferences.
Device support on ScotiaConnect mobile tracks recent major iOS releases and Android devices on a modern security-patch level. Older operating-system versions are blocked at sign-in, because the cryptographic primitives and jailbreak-detection paths the app depends on rely on platform features that older versions do not provide. Biometric unlock uses the platform biometric API directly, meaning Face ID and Touch ID on iOS and fingerprint or face unlock on supported Android devices. Biometrics never replace the second factor; they reduce how often the user has to re-enter it.
Device binding is the counterpart to biometrics. Each ScotiaConnect install is bound to the underlying device at first sign-in, which prevents an exported credential store from being used on a different device. Jailbreak and root detection runs at app launch and blocks sign-in when a tampered state is detected. The same logic blocks attached debuggers and certain proxy conditions that would otherwise compromise the authentication trust model.
The ScotiaConnect mobile app is optimized for balance review, payment approval and positive-pay decisions. Payment initiation for higher-value batches stays desktop-first, because the dual-control workflow and the file-import flow are not well suited to a phone screen.
Mobile is the approver's surface on ScotiaConnect. A typical approver logs in, reviews a short queue of pending batches, taps through to the batch detail, confirms the amounts and approves. Positive-pay decisions follow the same pattern: a short list of exception items, each with the scanned image, approved or returned with one tap. Balance review works similarly, with cards for primary operating accounts, a scrollable list for secondary accounts, and a tap-through to the transaction history surface for deeper investigation.
Origination is deliberately limited on mobile. Very small, pre-templated payments can be initiated, but anything that crosses the company's dual-control threshold requires the desktop surface. This is a conscious product decision: the file-import flows, template building and complex approval routing used for high-value batches do not translate cleanly to a phone. US-side rails referenced through the Federal Reserve's Federal Reserve calendar also carry timing sensitivities that are easier to handle on desktop.
Offline behaviour on ScotiaConnect mobile is deliberately narrow. The app shows the last-viewed screen as a read-only placeholder when connectivity drops, but no transactional data is cached to disk. Reconnecting forces a session refresh; if the session has expired, the user re-authenticates. This narrow offline model is the main reason the mobile app does not require the same data-at-rest protections as a full offline-capable client.
Push notifications are scoped by category and each category has its own preference. Balance-threshold, payment-approval, login and security categories can be enabled or disabled independently. Quiet-hours suppress non-urgent pushes overnight while still allowing security categories to reach the user. See account alerts for the desktop side of the same notification model.
| Feature | Mobile supported | Desktop alternative |
|---|---|---|
| Balance review | Full | Full desktop dashboard |
| Transaction history browse | Full | Full desktop grid with export |
| Payment approval | Full | Full desktop approval queue |
| Payment initiation (low-value) | Limited, pre-templated only | Full desktop initiation |
| Payment initiation (high-value) | Not available | Full desktop initiation |
| Positive-pay decisions | Full | Full desktop positive-pay queue |
| File import | Not available | Desktop file-import flow |
| Statement download | Read-only PDF | Full export surface |
“The ScotiaConnect mobile app is how I approve batches when I am out of the office. Biometric unlock, one tap to the queue, one confirmation per batch. The desktop is still where the preparer builds the file, but the approver side is mobile-native.”
— Bogdan P. WeidenfeldAuthorized Signatory, Springbrook Grocers Co.
ScotiaConnect mobile supports current-generation iOS devices from recent major releases and Android devices running a modern security-patch level. Older operating-system versions are blocked at sign-in to maintain the cryptographic and jailbreak-detection posture the app depends on.
Device support windows are published and communicated through the service desk in advance of cut-over dates.
Yes. ScotiaConnect mobile supports Face ID and Touch ID on iOS and fingerprint and face unlock on supported Android devices. Biometric unlock is a convenience factor layered on top of a recent passcode entry; the underlying authentication factor is still the hardware or soft-token second factor.
Biometrics reduce how often the second factor needs to be re-entered, without replacing it.
Payment initiation for high-value batches remains desktop-first on ScotiaConnect. The mobile app is optimized for balance review, payment approval and positive-pay decisions, which matches the dual-control expectation for higher-value items.
Small, pre-templated payments can be initiated on mobile, but anything that crosses the company's dual-control threshold requires the desktop surface.
ScotiaConnect mobile detects jailbreak and root conditions at app launch and blocks sign-in when a tampered device state is detected. The app will also refuse to run when certain debugger or proxy conditions are present, since those conditions compromise the trust model of the authentication flow.
Users on detected tampered devices are routed to re-install the app on a supported, untampered device.
Yes. ScotiaConnect mobile supports per-category push preferences for balance thresholds, payment approvals, login alerts and security notices. Users can disable categories individually, and quiet-hours can be set to suppress non-urgent pushes overnight.
Security-category pushes continue to reach the user during quiet-hours, because the category is reserved for conditions that warrant immediate attention.