| MFA from the device identifier, a PIN and an app-specific identifier, with accounts used only on registered devices | Guideline No. 01/2020, clauses 5.1, 5.3, 5.5, 6.1 and 6.4 ↗ | A FortAuth passkey is created in the secure element of the registered phone for that app's domain, so it is both the device identifier and the app-specific identifier, and it cannot be copied to another phone. The biometric or PIN that unlocks it happens on the device, which is the exception clause 6.1 allows, and the signature is verified at the bank's backend. The bank keeps the mobile number registration that clause 5.1 requires; the passkey adds to it rather than replacing it. | FortAuth |
| A login authentication and a separate financial value-based transaction authentication for each account | Guideline No. 01/2020, clause 5.4 ↗ | FortAuth runs one passkey ceremony at login and a second for each payment. With Secure Payment Confirmation, the amount and payee are shown on the device and bound into the signed data, so the transaction authentication covers the value approved, not only the session. When a customer speaks a payment through FortVoice, the transcribed command is shown on the phone and goes through that same transaction authentication before it executes. | FortAuthFortVoice |
| Secondary devices approved from the primary device, central disabling of lost devices, and anomaly alerts | Guideline No. 01/2020, clauses 5.2, 6.6, 8.5 and 8.6 ↗ | A new phone can be enrolled only after the customer approves it with the passkey on their primary device, the first route clause 5.2 names. Each device holds its own credential, so the bank can revoke a lost or stolen phone's passkey centrally without touching the others. Every ceremony is logged with device, time and outcome, and these events feed the real-time monitoring and customer notifications that clauses 6.6 and 8.5 require. The clause's call-centre route means a human officer; FortAgent is not offered as a substitute for that person. | FortAuth |
| User activity logs adequate to establish accountability without repudiation | Banking Act Directions No. 16 of 2021, Schedule I, clause 5.3.5 ↗ | A passkey assertion is a signature from a key that only the customer's device holds, so each logged login or payment approval is tied to that device and that moment. A shared code would only show that someone entered it. FortAgent adds a transcript, QA score and audit trail for every call, and FortVoice records the command the customer confirmed, so access to and changes of customer data through voice channels can be traced as well. | FortAuthFortAgentFortVoice |
| Infrastructure ownership, management and location, and customer consent for third-party or offshore hosting | Banking Act Directions No. 16 of 2021, Schedule I, clauses 9.2, 9.3.2 and 9.9.3 ↗ | All three products can be installed on the bank's own infrastructure in Sri Lanka and run by its own staff. That is the bank owned and managed, located in Sri Lanka model, for which clause 9.2 sets no additional requirements, and it keeps customer data out of the third-party infrastructure that triggers the consent step in 9.9.3. FortVoice processes speech inside that estate rather than at a global endpoint. If the bank chooses third-party cloud instead, the certification, Board-approval and consent conditions in 9.8 and 9.9 apply to that arrangement. | FortAuthFortVoiceFortAgent |
| Introducing the caller, the institution and the purpose on outbound calls, and keeping call recordings and a call register | Financial Consumer Protection Regulations No. 01 of 2023, Regulations 23.3 and 23.4 ↗ | Every FortAgent call opens by telling the customer they are speaking to an AI agent, naming the bank and stating why it is calling, which goes further than Regulation 23.3 asks of a human caller. Each inbound and outbound call is recorded, transcribed and listed with its time, number and outcome, giving the bank the recordings and call register that 23.4 requires. The bank sets how long they are kept. | FortAgent |
| Liability for, and monitoring of, agents and third parties dealing with customers, including outsourced recovery calls | Financial Consumer Protection Regulations No. 01 of 2023, Regulations 27.2, 27.4 and 28.3(xi); Banking Act Directions No. 01 of 2026, Schedule I, 8.1 ↗ | Because the bank is liable for what is said on its behalf, FortAgent QA-scores every call against the bank's own script and consumer-protection rules, so monitoring covers every call rather than a sample. The bank sets the calling windows for outbound campaigns, so collections calls can be kept out of the 9.00 pm to 6.00 am period that Regulation 28.3(xi) bars. Direction 8.1 speaks of training the provider's staff; the transcripts and scores are the evidence the bank can show for an automated agent instead. | FortAgent |
| Liability for customer losses from fraud unless the provider proves the customer's negligence | Financial Consumer Protection Regulations No. 01 of 2023, Regulations 22.1 and 48(i) ↗ | A passkey is bound to the bank's genuine domain, so it will not sign in to a phishing site, and there is no code a fraudster can talk the customer into reading out. That removes the most common route to the losses Regulation 48(i) puts on the provider. Where a payment is disputed, the signed record shows which registered device approved which amount and payee, which is the evidence the bank needs to establish what happened. | FortAuth |
| Security, protection and safety features in mobile apps offered in both text and audio | Financial Consumer Protection Regulations No. 01 of 2023, Regulations 13.2(ii) and 17.3(v) ↗ | FortVoice gives the app a spoken route to banking actions, with each command confirmed before it executes, alongside the on-screen route. FortAuth replaces typed codes with the phone's own fingerprint or face prompt, which works with the device's screen reader. Together they let a customer with low vision complete a secured transaction without reading an SMS code. | FortVoiceFortAuth |
| Controller and processor safeguards for personal data, including call recordings and transcripts, from 1 January 2027 | Personal Data Protection Act, No. 9 of 2022, sections 10, 21(1) and 22(1); section 26 as replaced by Act No. 22 of 2025; commencement under Gazette Extraordinary No. 2498/16 ↗ | Recordings, transcripts and voice commands are personal data the bank controls. Where we host them, we act as processor on the bank's written instructions, under confidentiality obligations, open to the bank's audits, and erase or return the data when the service ends, as section 22(1) sets out. In an on-premise deployment the data never leaves the bank, so no cross-border flow under section 26 arises. FortAuth stores only public keys, and biometric data stays on the customer's device. | FortAgentFortVoiceFortAuth |