Security arrangement for financial technology platforms

Abstract

The invention discloses a security arrangement for a financial transactional platform including a 3rd step in authentication for an online electronic fund transferring platform or in app authentication for transactions on mobile devices or web-based platforms, and adapted to be utilised by a client and / or user, which includes at least one of the following means to activate and / or trigger duress mode during the login process; while logged in to the FTP under normal conditions; on a third-party mobile phone / device; and / or duress mode can be triggered on the client's / user's device while transacting at an ATM, POS or payment gateway.

Description

[0001] SECURITY ARRANGEMENT FOR FINANCIAL TECHNOLOGY PLATFORMS

[0002] FIELD OF INVENTION

[0003] The present invention relates to a security arrangement for financial technology platforms.

[0004] More particularly, the present invention relates to a security arrangement for financial technology platforms as a security add on and also for banking application security and other transactional platforms including trading platforms, crypto platforms and investment platforms.

[0005] BACKGROUND TO INVENTION

[0006] Mobile banking is an electronic service provided by a bank or other financial institution that enables its customers to conduct financial transactions remotely using a mobile device such as a smartphone or tablet. Unlike the related internet banking it uses software, usually called an app, provided by the financial institution for this purpose. Mobile banking is generally available on a 24-hour basis and some financial institutions have restrictions on which accounts may be accessed through mobile banking, as well as a limit on the amount that can be transacted. Mobile banking is furthermore dependent on the availability of an internet or data connection to the mobile device. Transactions through mobile banking depend on the features of the mobile banking app provided and typically includes obtaining account balances and lists of latest transactions, electronic bill payments, remote check deposits, P2P payments, and funds transfers between a customer's or another's accounts. In addition, some banking apps also enable copies of statements to be downloaded and sometimes printed at the customer's premises. Using a mobile banking app increases ease of use, speed, flexibility and also improves security because it integrates with the user built-in mobile device security mechanisms.

[0007] Mobile banking reduces the cost of handling transactions by reducing the need for customers to visit a bank branch for non-cash withdrawal and deposit transactions and in addition mobile banking does not handle transactions involving cash, and a customer needs to visit an ATM or bank branch for cash withdrawals or deposits.

[0008] As with most internet-connected devices, as well as mobile-telephony devices, cybercrime rates are escalating year-on-year and the types of cybercrimes which may affect mobile-banking might range from unauthorized use while the owner is using the mobile banking, to remote-hacking, or even jamming or interference via the internet or telephone network data streams. This is demonstrated by the malware called SMSZombie. A, which infected Chinese Android devices. The malware was embedded in wallpaper apps and installed itself so it can exploit the weaknesses of China Mobile SMS Payment system, stealing banks credit card numbers and information linked to financial transactions. A malware discovered recently was the Trojan called Bankbot which went past Google's protections in its Android app marketplace and targeted mobile banking customers on Android devices worldwide before its removal by Google in September 2017.

[0009] In the banking world, currency rates may change by the millisecond and security of financial transactions, being executed from some remote location and transmission of financial information over the air, are the most complicated challenges that need to be addressed jointly by mobile application developers, wireless network service providers and the banks' IT departments.

[0010] One-time passwords (OTPs) are one tool used by financial and banking service providers in the fight against cyber fraud. Instead of relying on traditional memorized passwords, OTPs are requested by consumers each time they want to perform transactions using the online or mobile banking interface. When the request is received, the password is sent to the consumer's phone via SMS. The password is expired once it has been used or once its scheduled life cycle has expired. People are being hijacked and kidnapped and their mobile phones / devices / PC's are then used by the criminals to gain access to their banking applications or any other financial technology platform (FTP) that can be used to transfer funds in various forms of currency, including cryptocurrency, decentralized finance platforms as well as mobile wallets such as Apple Pay, Google pay etc. or any other e-commerce platform. This is done under duress and the person's (Biometrics) face ID or fingerprint, and login details can be used to do this, or they may just be forced at gunpoint to access their banking or Financial Technology Platform Profile for the criminals. The criminals then transfer all available funds out of the victim's account.

[0011] The bank or any other financial technology platform is not obligated to refund the victim as they were not at fault in respect of this theft, much like someone who's house is broken into and hard currency is stolen, it is out of the bank's or financial technology platform's control.

[0012] It is an object of the invention to suggest a novel security arrangement which will assist in overcoming the aforementioned problems, namely to create a security feature in financial technology platforms, mobile applications and online platforms or websites that will not only safeguard the victim's funds but also provide and activate the services of an armed response and / or kidnap / ransom task force / negotiating team thereby giving the opportunity to rescue the victim if they are held against their will, by providing such teams with a geolocation of the person being held and forced to access their account under duress.

[0013] SUMMARY OF INVENTION

[0014] According to the invention, a security arrangement for a financial transactional platform includes a 3rd step in authentication for an online electronic fund transferring platform or in app authentication for transactions on mobile devices or web-based platforms, and includes at least one of the following means to activate and / or trigger duress mode

[0015] (a) during the login process;

[0016] (b) while logged in to the FTP under normal conditions;

[0017] (c) on a third-party mobile phone / device; and / or

[0018] (d) while transacting at an ATM, POS or payment gateway.

[0019] Upon Logging in to the online electronic transferring platform by the bank's required means, such as biometric login on a mobile device or using an in app authentication, One Time Pin protocol or QR code for a web based or desktop application access, the banking client / user would then also be required to enter a PIP (Personal Identification Protocol) on their phone / mobile device (e.g. via a push notification in their banking app, or directly in the banking app), this could be in the form of a PIN, Password, Pass Phrase, alternate Biometrics, physical security key or second user / person / device or any other means of authentication, to access their online banking application or website; by entering a correct PIP, normal banking profile access will be granted, however should an incorrect PIP be used, or a duress pin, reversed pin, predetermined duress PIP, or any other predetermined method of indicating duress (e.g. Outside predetermined geofence, outside predetermined transactional times, etc), the banking app / website will still be opened, but in a "Duress Mode", the phone or mobile device used to trigger the duress mode may trigger various duress profiles as determined by the bank and / or client.

[0020] While logged in to the banking app or website normally and not under duress, certain parameters may be set to trigger a duress mode as an additional safety feature for the client / user, this will also trigger the silent duress profile.

[0021] While transacting at an ATM or POS, parameters are set to trigger a duress mode, e.g. large transaction amount, geolocation, multiple withdrawals and similar.

[0022] A family member's or business partner's (Third Party) mobile device could be triggered into duress mode.

[0023] The Duress mode will trigger a security protocol and / or a duress profile based on the type of activation. Duress mode is triggered at the login stage, but the Banking Profile will be the full profile of the client / user; however, the bank will then be aware that the client / user and profile is under duress and the Profile will have no changes to it and will be fully functional, this can be described as an "unchanged under duress profile".

[0024] Alternatively if this feature is implemented, a simpler / alternate profile will open and appear to be the person's normal bank account, namely an "under duress profile", and any additional profiles and / or accounts the client / user has, may or may not be visible / accessible and may or may not have decreased functionality or visible funds and / or reduced accessible amounts; and / or this the profile has accounts with a reduced balance visible and "available"; and / or any access bond accounts, Investment accounts, offshore accounts, share / trade accounts may or may not be visible and if visible may or may not have a reduced amount; and / or these amounts can be determined by the bank and could be generated randomly if need be or possibly be determined by the bank's client; and / or the rest of the banking app / website will have full and normal functionality i.e. being able to add beneficiaries, increase daily limits for transferring funds, perform instant EFT's etc. In other words, it should "look and feel" exactly like the normal online banking facility. A Security Protocol is activated when the "Under duress profile" or "Unchanged Under Duress Profile" is activated.

[0025] The arrangement may include at least one of the following protocols:

[0026] (a) If a website or desktop application on a PC, Desktop, laptop, notebook, tablet, or other device is used, the client' s / user's mobile device will be triggered to activate duress mode on their mobile device application;

[0027] (b) The bank's security / fraud division is immediately be made aware that a duress profile has been activated;

[0028] (c) The IP address of the PC, desktop, tablet or any other device is logged and sent to the bank.

[0029] At least one of the following is triggered on the client's / user's mobile device / phone:

[0030] (a) A GPS location is sentto the bank, and / or security company / kidnap and Ransom Task Force;

[0031] (b) This GPS location is a "live view" and "always on";

[0032] (c) The GPS location is available to the bank or security company / kidnap and Ransom Task Force even if the app / website is closed down or logged out of; (d) Cell tower triangulation or any other means of determining the device's location is activated;

[0033] (e) a message / notification of the incident is sent to the client's nominated contact or contact list.

[0034] The GPS location is available, even if the mobile device / phone is turned off (If possible / available on the device, as in the case with iPhone), in order to allow the mobilization of an Armed Response / Kidnap / Ransom negotiating team and give them the exact location and opportunity to rescue the victim if they are held against their will; and if the GPS location is disabled in the mobile device or phone's settings, then the banking app will not be able to log in, nor should it be allowed to authenticate a log in on a website or other device or platform.

[0035] The Device's camera and microphone may also be activated to monitor the surrounding environment and recorded remotely; this could be on the mobile device as well as laptop / PC.

[0036] The arrangement may include at least one of the following features:

[0037] (a) The funds that are transferred out of the account should appear to have left the account and appear to be deposited into the receiving bank account used by the criminal, but there could be a delayed, reversable, or fake transaction; (b) The receiving bank used by the criminal should be informed that these funds are stolen and upon receipt of the stolen funds or notification thereof, the receiving bank could send a fake transaction confirmation message;

[0038] (c) The funds are flagged as "under duress funds" and may be a "fake" entry into the receiver's account so that it appears as if the funds have been transferred;

[0039] (d) The transactions are blocked by collaboration with the receiving bank; and / or

[0040] (e) These funds appearing in the receiver's account may require a clearance time before the funds are available and thus allows the bank to reverse the transactions or deal with them in any manner they deem fit, an example would be to require the account holder of the stolen funds to come into the bank and then be dealt with accordingly.

[0041] A Silent Duress Profile may be activated in the following manner:

[0042] (a) if a client / user is afraid of activating the duress mode, certain transaction parameters (such as a pin is required for a large transfer amount or for when a beneficiary is added; then a duress pin, reverse pin or wrong pin is entered) or "transactional flags" should trigger a "silent duress profile.";

[0043] (b) The "Silent Duress Profile" will be the client's / user's normal profile with full functionality;

[0044] (c) The bank and armed response will be notified that the "silent duress profile" has been activated;

[0045] (d) The funds that are transferred out of the account appear to have left the account and be deposited into the criminal's account, there could be a delayed, reversable, or fake transaction;

[0046] (e) The criminal's bank is informed that these funds are stolen;

[0047] (f) Upon notification or receipt of the stolen funds the receiving bank could send a fake "transaction confirmation message";

[0048] (g) These funds are flagged as "under duress funds" and may be a "fake" entry into the criminal's account so that it appears as if the funds have been transferred;

[0049] (h) It appears that the funds have cleared but in reality the funds appearing in the criminal's account may require a clearance time before the funds are available and thus allow the bank to reverse these transactions or deal with them in any manner they deem fit, an example would be to require the account holder of the stolen funds to come into the bank and then dealt with accordingly.

[0050] A Silent Duress Profile may be activated in at least one of the following manners: Transactional Flags selected from the group consisting of: PIN Code Variation, Biometric Duress Signal, Voice Command, Silent Button Activation, Long Press or Gesture, Accelerometer or Device Movement, Geolocation Triggers, Facial Recognition Duress Signal, Wearable Device Integration, Time-Based Activation, loT / Connected Device Signal, Double Authentication Attempt, Delayed Authentication, Preconfigured Companion Signal, Camera-Based Signals, Application Interface Triggers, Proximity Sensor Activation, Headphone Jack or Accessory Input, Bluetooth Device Signal, Custom Tap Sequences, Battery Status Trigger, Screen Pattern Variations, Environmental Noise Detection, Silent Signal from Another Device, NFC Tag or Card, Custom Swipe Gestures, Multiple Device Sync, Power Button Code, Device Removal or Disconnection, Simulated App Crash, Temperature Sensor Triggers, Gaze Detection, Heartbeat or Stress Level Monitoring, Haptic Feedback Signals, Al Behavioral Analysis, Incorrect Login Attempts, Constant Face Scanning; Abnormal transactions;. Preset transaction rules; Addition of Biometrics. A Family Member / Partner Alternative Device Duress Mode is activated if a Family member / partner (or any other nominated person) is kidnapped and demands are made for the family to transfer funds, and in which there are one or both of the following scenarios:

[0051] (a) If the family member / partner / associate etc. has the same banking app, the person that has been requested to perform the transfer of funds can tell the kidnappers that the person who is kidnapped is responsible for authentication of large transfers, this will activate the duress mode on the kidnapped persons phone, this will also cause the kidnappers to turn the phone on, should it have been turned off; this can be done in the following manner: Individual "Third Party Duress Contacts" should be preloaded on the client's profile; The bank is immediately notified that a Family member / partner is held under duress; this is done by various means such as calling the bank, activation within the banking site or app by a link or any other means determined by the bank; the kidnapped person's "Third Party Duress Contact" can be selected from within the client's profile thereby activating the "Family member / Partner Alternative Device Duress Mode"; a transaction authentication ("In app authentication" or "One Time Pin" etc, that has to match the sender's pin) or any other form of transaction authentication protocol is sent to the kidnapped persons phone, by entering / acknowledging the authentication protocol such as an in-app message or OTP, the kidnapped person's phone and banking app will enter duress mode; the transactions will appear to have gone through but would be flagged as under duress; an additional option would be that the first transaction authentication "fails" which still activates the duress security protocol, but does not initiate the "transfer of funds"; the kidnappers can be called a while later to be advised that the transaction failed and has to be authorized again; alternatively, the kidnappers can be told that the first authorization on the kidnapped persons phone is to transfer funds from a "holding / investment" account and once the funds are in the "current account" a second authorization is required to transfer the funds to the Kidnappers account; this will provide time for the security task force to be mobilized; the Duress Security Protocol will be activated on the kidnapped person's phone or mobile device and / or the device authorizing the fund transfer;

[0052] (b) If the kidnapped person banks with a different bank and the family / partner / associate etc. is contacted to make a payment, there can be a kidnapping hotline that can be called for that specific bank; alternatively, Individual "Third Party Duress Contacts" should be preloaded on the client's profile, these "Third Party Duress Contacts" should include links that can cross communicate with other banks and their apps / websites via push notifications, in app authentication or even just an acknowledgment of an OTP, or any other means that allows the kidnapped person's bank to be notified; The kidnappers can be told that the kidnapped person is responsible for authenticating large transactions; a transaction authentication ("In app authentication" or "One Time Pin") or any other form of transaction authentication protocol is sent to the kidnapped persons phone, by their bank. By entering / acknowledging the authentication protocol such as an in-app message or OTP, or any other means, the phone and banking app will enter duress mode; this will activate the duress mode on the kidnapped persons phone, this will also cause the kidnappers to turn the phone on, should it have been turned off; these messages can be sent directly from the kidnapped persons bank as a standalone message to activate duress mode or may be used in conjunction with the person's bank that is making the transfer, thereby activating the "Family member / Partner Alternative Device Duress Mode"; the transactions will appear to have gone through but would be flagged as under duress; an additional option would be that the first transaction authentication "fails" which still activates the duress security protocol, but does not initiate the "transfer of funds". The kidnappers can be called a while later to be advised that the transaction failed and has to be authorized again. Alternatively, the kidnappers can be told that the first authorization on the kidnapped persons phone is to transfer funds from a "holding / investment" account and once the funds are in the "current account" a second authorization is required to transfer the funds to the Kidnappers account; this will provide time for the security task force to be mobilized; the Duress Security Protocol will be activated on the kidnapped persons phone or mobile device and / or the device authorizing the fund transfer.

[0053] An in app or push notification PIP may be required as an additional authentication method for logging in to a person's account on an ATM. Should an incorrect PIP or duress pin be used, then the duress mode will be triggered on the person's mobile phone.

[0054] Should a person be forced to withdraw cash from an ATM or POS, an in app duress pin, or incorrect PIP for the transaction could trigger a duress mode on the mobile phone of the person withdrawing funds; the PIP may be required for every ATM or POS transaction or only when a person withdraws cash over a certain amount or consecutive withdrawals; should an incorrect PIP or duress pin be used, then the duress profile may be activated on the ATM or POS and duress mode will be triggered on the mobile phone; The Duress Security Protocol will be activated on the person's phone or mobile device.

[0055] If the incorrect PIP, duress PIN, or any other method used to activate duress mode is entered by mistake, and the client realizes the error, they should be able to notify the bank (e.g. Telephonically) to begin restoring normal account functionality through reactivation authentication; The bank may verify the client's identity using a secure method such as a passcode, passphrase, or knowledge-based questions (KBQs); if the correct responses are provided, the account can be reactivated within a standard timeframe— typically 24 hours— or sooner / later based on the client's request or the bank's policy. Depending on the bank's procedures, this may restore either limited or full access to the account and its features; in addition, the bank may offer an online or in-app option to reverse duress mode; this would require entry of a designated PIN, passphrase, PIP, or successful completion of KBQs or other authentication mechanisms determined by the bank. The live GPS location must still be available during this period in case the client has been forced to call the bank / cancel the duress mode; the bank can then ask them for a passcode, passphrase, or any other manner to determine if the client is still under duress or if an actual mistake was made; if the correct reactivation authentication (password / passphrase / predetermined answers to questions etc.) is given then the account may be reactivated in 24 hours, or any other time frame as requested by the client or as determined by the bank, this may enable immediate limited functionality and transactions or full functionality; the bank / security task force / team could also ascertain whether the client is still under duress based on the client's geolocation or account interaction.

[0056] If they require full access to their account sooner, they can go to their nearest branch to report in person that everything is ok, should this be a requirement of the bank.

[0057] If a kidnapper is aware that the person they kidnapped has activated the Duress Mode on their Banking app or website, they may force the client / user to deactivate the Duress Mode, in a manner described above or any other way the bank may require; should the client / user be forced to cancel the Duress Mode with reactivation authentication, an alternative "panic" password / pin / PIP, giving incorrect answers to knowledge based questions, or simply an incorrect PIP can be given or used that doesn't match the registered reactivation authentication method, triggering the unchanged under duress profile, allowing full restoration of the electronic banking website or App, thereby creating the perception to the kidnappers that full functionality of the client's profile has been restored and the duress situation has been cancelled; the Duress Security Protocol will remain active on the person's phone or mobile device.

[0058] The bank may elect to provide the client with insurance to cover loss of funds under duress, to provide armed response when the duress profile is activated and also kidnap and ransom insurance including release and / or rescue negotiation and / or the bank may opt to outsource the insurance to a third party.

[0059] The bank may provide the services of such as task force for rescuing the person held under duress and / or the bank may opt to outsource such services.

[0060] Also, according to the invention, a security method for a financial transactional platform includes a 3rd step in authentication for an online electronic fund transferring platform or in app authentication for transactions on mobile devices or web-based platforms, which includes the step of activating and / or triggering duress mode by means of at least one of the following:

[0061] (a) during the login process;

[0062] (b) while logged in to the FTP under normal conditions; (c) on a third-party mobile phone / device; and / or

[0063] (d) duress mode can be triggered on the client's device while transacting at an ATM, POS or payment gateway.

[0064] Yet further according to the invention, a security arrangement for a banking app, which includes the following security functions:

[0065] (a) the person user of the banking app is required to enter a PIP to access their online banking platforms;

[0066] (b) should an incorrect PIP be entered, the online banking app / website will still be opened, but with the following occurring: a. any additional profiles the person has will not be visible; and / or b. a Simple profile will open up and appear to be the persons normal bank account - this profile will be an "under duress" profile and will have a reduced accessible amount visible and "available".

[0067] The reduced accessible amounts available may include those of any access bonds and / or market accounts and / or savings accounts.

[0068] These reduced accessible amounts may be determined by the bank.

[0069] These reduced accessible amounts may be generated randomly if necessary or possibly be determined by the bank's customer. The rest of the bank app / website may have full and normal functionality, namely being able to increase daily limits for transferring funds.

[0070] In other words, it may "look and feel" exactly like the normal online banking facility.

[0071] The criminals may be able to transfer funds to other bank accounts, with instant transfers as per transaction request.

[0072] If the incorrect PIP is entered and the "duress profile" is activated, the following steps may be activated:

[0073] (a) The bank's security / fraud division may immediately be made aware that a duress profile has been activated;

[0074] (b) A GPS location may be sent to the bank;

[0075] (c) The GPS location may be a "live view";

[0076] (d)The GPS location may still be available to the bank even if the app / website is closed down.

[0077] The above may allow the mobilization of an armed response / kidnap negotiating team and give them the exact location and opportunity to rescue the victim if they are held against their will. If the GPS location is disabled in the mobile device or phone's settings, then the banking app may not be able to log in.

[0078] The funds that are transferred out of the account may appear to have left the account and be deposited into the criminal's account.

[0079] These funds may be flagged as "under duress funds" and may be a "fake" entry into the criminals account so that it appears as if the funds have actually been transferred.

[0080] Alternatively, these funds appearing in the criminals account may be flagged as such and a clearance time is required before the funds are available.

[0081] This may allow the bank to reverse these transactions.

[0082] If the incorrect PIP is entered in error and the customer realizes this, then they should be able to call the bank and advise them of this.

[0083] Full access to their account may only be available in 24 hours or longer if needed.

[0084] The live GPS location may still be available during this period in case they have been forced to call the bank.

[0085] The bank may then ask them for a passcode, if the correct passcode is given then the account will be reactivated in 24 hours. If an incorrect passcode is given, the response team may be sent to their location.

[0086] If they require access to their account sooner, they may go to their nearest branch to report in person that everything is ok.

[0087] The security features and application thereof may cover not only mobile banking apps, but online banking via websites as well.

[0088] The arrangement may include any online or mobile trading platform, whether it is for forex, cryptocurrency, share trading.

[0089] The arrangement may cover any mobile or online trading (apps and websites) where cash / currency or shares / stock can be transferred to other entities / accounts to safeguard against these transfers when or if the user is under duress.

[0090] Normal functionality of the arrangement may also include adding beneficiaries or doing a one-time transfer / payment to a beneficiary not listed.

[0091] The Financial Technology Platform / Bank / client may decide to use the security application in various configurations, an example would be requiring the PIP at log in stage only at selected times / locations, however the in app authentication PIP will always be active (based on in app authentication parameters) to ensure there is always a level of protection. BRIEF DESCRIPTION OF DRAWING

[0092] The invention will now be described by way of example with reference to the accompanying schematic drawing.

[0093] In the drawings there is shown the login page sequence of a financial transactional App or website according to the invention.

[0094] DETAILED DESCRIPTION OF DRAWING

[0095] Referring to the drawing, there is shown a financial transactional App or website according to the invention.

[0096] A security arrangement for financial technology platforms includes the following steps a 3rd step in authentication in an online electronic fund transferring platform, or in app authentication for transactions on mobile devices or webbased platforms, including at least one of the following means in order to activate and / or trigger a duress mode:

[0097] (a) during the login process;

[0098] (b) while logged in to the FTP under normal conditions, duress mode can be triggered / activated;

[0099] (c) on a third-party mobile phone / device; and / or (d) on the client' s / user's device while transacting at an ATM, POS or payment gateway.

[0100] A Banking app / website with a single client will be used as an example but the same or similar functionality could be used for any user or on any other Financial Technology Platform, or mobile wallet, or even ATM or POS cash withdrawals or electronic transactions.

[0101] Example

[0102] Upon Logging in to the online electronic fund transferring platform such as a banking app, website, or online platform; by the bank's required means, such as biometric login on a mobile device or using an in app authentication, One Time Pin protocol or QR code for a web based or desktop application access, the banking client / user would then also be required to enter a PIP (Personal Identification Protocol) on their phone / mobile device (e.g. via a push notification in their banking app, or directly in the banking app), this could be in the form of a PIN, Password, Pass Phrase, alternate Biometrics, physical security key or second user / person / device or any other means of authentication, to access their online banking application or website. By entering a correct PIP, normal banking profile access will be granted. Should an incorrect PIP be used, or a duress pin, reversed pin, predetermined duress PIP, or any other predetermined method of indicating duress (e.g. Outside predetermined geofence, outside predetermined transactional times, etc), the banking app / website will still be opened, but in a "Duress Mode", the phone or mobile device used to trigger the duress mode may trigger various duress profiles as determined by the bank and / or client.

[0103] While logged in to the banking app or website normally and not under duress, certain parameters may be set to trigger a duress mode as an additional safety feature for the client, this will also trigger the silent duress profile.

[0104] While transacting at an ATM or POS, parameters could be set to trigger a duress mode, egg large transaction amount, geolocation, multiple withdrawals.

[0105] A family member's or business partner's (Third Party) mobile device could be triggered into duress mode.

[0106] The Duress mode will trigger a security protocol and / or a duress profile based on the type of activation, the information below will further explain the functionality.

[0107] Duress Mode Unchanged Duress Profile: Duress mode is triggered at the login stage, but the Banking Profile will be the full profile of the Client; however, the bank will then be aware that the client / user and profile is under duress. The Profile will have no changes to it and will be fully functional.

[0108] Duress Profile: A Simpler / Alternate profile will open and appear to be the person's normal bank account. This profile will be an "under duress" profile. Any additional profiles and / or accounts the client / user has, may or may not be visible / accessible and may or may not have decreased functionality or visible funds and / or reduced accessible amounts.

[0109] The profile may have accounts with a reduced balance visible and "available". Any access bond accounts, Investment accounts, offshore accounts, share / trade accounts may or may not be visible and if visible may or may not have a reduced amount. These amounts can be determined by the bank and could be generated randomly if necessary or possibly be determined by the bank's client.

[0110] The rest of the banking app / website will have full and normal functionality i.e. being able to add beneficiaries, increase daily limits for transferring funds, perform instant EFT's. In other words, it should "look and feel" exactly like the normal online banking facility. Any other methods of transferring funds such as Payshap, should also be functional. The Following Security Protocol will be activated when the "Under duress profile" or "Unchanged Under Duress Profile" is activated.

[0111] Duress Security Protocol: If a website or desktop application on a PC, Desktop, laptop, notebook, tablet, or other device is used, the client's mobile device will be triggered to activate duress mode on their mobile device application.

[0112] The bank's security / fraud division must immediately be made aware that a duress profile has been activated.

[0113] The IP address of the PC, desktop, tablet or any other device needs to be logged and sent to the bank.

[0114] The following should be triggered on the client's / user's mobile device / phone:

[0115] A GPS location needs to be sent to the bank, and / or security company / kidnap and Ransom Task Force.

[0116] This GPS location should be a "live view" and "always on".

[0117] This GPS location should still be available to the bank or security company / kidnap and Ransom Task Force even if the app / website is closed down or logged out of. Cell tower triangulation or any other means of determining the device's location should also be activated.

[0118] A message / notification of the incident can also be sent to the client's nominated contact or contact list.

[0119] The GPS location should be available, even if the mobile device / phone is turned off (If possible / available on the device, as in the case with iPhone).

[0120] This will allow the mobilization of an Armed Response / Kidnap / Ransom negotiating team and give them the exact location and opportunity to rescue the victim if they are held against their will.

[0121] If the GPS location is disabled in the mobile device or phone's settings, then the banking app will not be able to log in, nor should it be allowed to authenticate a log in on a website or other device or platform.

[0122] The Device's camera and microphone may also be activated to monitor the surrounding environment and recorded remotely; this could be on the mobile device as well as laptop / PC.

[0123] The funds that are transferred out of the account should appear to have left the account and appear to be deposited into the receiving bank account used by the criminal, there could be a delayed, reversable, or fake transaction. The receiving bank used by the criminal should be informed that these funds are stolen. Upon receipt of the stolen funds or notification thereof, the receiving bank used by the criminal could send a fake transaction confirmation message.

[0124] These funds must be flagged as "under duress funds" and may be a "fake" entry into the receiver's account so that it appears as if the funds have been transferred.

[0125] The transactions are blocked by collaboration with the receiving bank used by the criminal.

[0126] It appears that the funds have cleared but in reality the funds appearing in the receiver's account may require a clearance time before the funds are available. This will allow the bank to reverse these transactions or deal with them in any manner they deem fit, an example would be to require the account holder of the stolen funds to come into the bank and then dealt with accordingly.

[0127] Silent Duress Profile: A "Silent Duress Profile" may be activated as above, or in the following manner: If a client / user is afraid of activating the duress mode, certain transaction parameters (such as if a pin is required for a large transfer amount or for when a beneficiary is added; then a duress pin, reverse pin or wrong pin etc) or "transactional flags" should trigger a "silent duress profile." The "Silent Duress Profile" will be the client' s / user's normal profile with full functionality. The bank will be notified that the "silent duress profile" has been activated.

[0128] The funds that are transferred out of the account should appear to have left the account and be deposited into the criminal's account, there could be a delayed, reversable, or fake transaction. The criminal's bank should be informed that these funds are stolen. Upon notification or receipt of the stolen funds the receiving bank used by the criminal could send a fake "transaction confirmation message".

[0129] These funds must be flagged as "under duress funds" and may be a "fake" entry into the criminal's account so that it appears as if the funds have been transferred.

[0130] These funds appearing in the criminal's account may require a clearance time before the funds are available. This will allow the bank to reverse these transactions or deal with them in any manner they deem fit, an example would be to require the account holder of the stolen funds to come into the bank and then dealt with accordingly.

[0131] The Duress Security Protocol as above will be activated. Ways to Activate Silent Duress Mode

[0132] Transactional Flags: Transactional operations or user interactions with the FTP (e.g. Banking) application either directly or indirectly.

[0133] Should the FTP app require additional authentication for a transaction, change or addition of information such as loading a beneficiary, changing transaction limits, increasing loans or any other type of application interaction that the FTP would deem necessary for such authentication. This could be a single transactional flag or multiple transactional flags, which could be based on the risk of the interaction with the FTP.

[0134] 1. PIN Code Variation:

[0135] (a) Entering a specific alternative PIN or password that signals duress instead of the standard one.

[0136] (b) An incorrect pin or password entered either once or more times.

[0137] 2. Biometric Duress Signal:

[0138] Using a different fingerprint or a specific pattern of biometric input (e.g., intentionally scanning the wrong finger, closing one eye during facial recognition). 3. Voice Command:

[0139] (a) Saying a preconfigured duress phrase during a voice authentication process.

[0140] (b) If the banking app monitors background sounds for duress phrases or words, saying these words or phrases without being prompted to.

[0141] 4. Silent Button Activation:

[0142] Pressing a hidden or designated panic button within the application or on a physical device (e.g., pressing a function key a specified number of times)

[0143] 5. Long Press or Gesture:

[0144] Holding down a specific button (e.g., the login or power button) for an extended time, or using a particular gesture in the app.

[0145] 6. Accelerometer or Device Movement:

[0146] Triggering duress mode through abnormal device movements, such as sudden shaking, tapping or tilting.

[0147] 7. Geolocation Triggers: Automatically entering duress mode when the device is in a predefined high-risk location, or outside predetermined areas.

[0148] 8. Facial Recognition Duress Signal:

[0149] Using facial recognition with a specific expression or a subtle signal (e.g., blinking a set number of times, closing one eye).

[0150] 9. Wearable Device Integration:

[0151] (a) Activating duress mode through smartwatches or other wearables by pressing a hidden button or sending a predefined signal.

[0152] (b) Syncing heart rate, breathing rate, skin conductivity or any other biometric signal that would indicate the user is under stress.

[0153] 10. Time-Based Activation:

[0154] Logging in at an unusual or predefined "danger time" that activates duress mode automatically.

[0155] 11. loT / Connected Device Signal:

[0156] Triggering duress mode via connected smart devices, such as a smart lock or a connected home system.

[0157] 12. Double Authentication Attempt: Trying to authenticate twice in quick succession to signal distress.

[0158] 13. Delayed Authentication:

[0159] Intentionally taking longer than usual to complete the authentication or confirmation process, triggering an alert to security systems.

[0160] 14. Preconfigured Companion Signal:

[0161] (a) Sending a covert alert to a predesignated companion or security contact via the app, OTP, SMS, e-mail, any other form of electronic communication or a paired device.

[0162] (b) If the signal is not acknowledged it will activate duress mode.

[0163] 15. Camera-Based Signals:

[0164] Using the device's camera to detect subtle visual signals, such as showing a predefined object or a specific gesture.

[0165] 16. Application Interface Triggers:

[0166] Activating duress mode through inconspicuous Ul interactions, such as tapping a specific area of the screen multiple times or in a certain pattern.

[0167] 17. Proximity Sensor Activation: Triggering duress mode when the device detects an object or hand placed near the proximity sensor in a predefined way.

[0168] 18. Headphone Jack or Accessory Input:

[0169] Plugging in or unplugging headphones or a specific accessory in a particular sequence to signal duress.

[0170] 19. Bluetooth Device Signal:

[0171] Sending a duress signal through a connected Bluetooth device, such as earbuds or a smart key fob.

[0172] 20. Custom Tap Sequences:

[0173] Tapping a sequence (e.g., Morse code) on the device's screen or hardware buttons or triggering the device accelerometer to activate duress mode.

[0174] 21. Battery Status Trigger:

[0175] Configuring the device to enter duress mode when the battery level reaches a specific, unusual percentage (e.g., 13%).

[0176] 22. Screen Pattern Variations:

[0177] Drawing a slightly different pattern on the lock screen to activate duress mode. 23. Environmental Noise Detection:

[0178] Using the microphone to detect specific ambient sounds or keywords that activate duress mode (e.g., a distress word shouted).

[0179] 24. Silent Signal from Another Device:

[0180] Triggering duress mode on the primary device through another connected device, such as sending a signal from a paired smartphone or smartwatch.

[0181] 25. NFC Tag or Card:

[0182] Scanning an NFC tag, card, or token programmed to activate duress mode discreetly.

[0183] 26. Custom Swipe Gestures:

[0184] Using predefined swipe patterns (e.g., swiping left-right-left) in the app or on the device screen to trigger duress mode.

[0185] 27. Multiple Device Sync:

[0186] Activating duress mode when two devices synchronised to the same account behave inconsistently (e.g., one device logs in, but the other sends a distress signal).

[0187] 28. Power Button Code: Pressing the power button a specific number of times in quick succession (e.g., five presses) or long press to signal duress.

[0188] 29. Device Removal or Disconnection:

[0189] Automatically activating duress mode if the device is disconnected from a trusted network, charger, or docking station unexpectedly.

[0190] 30. Simulated App Crash:

[0191] Exiting the app in a way that appears to be an accidental crash but secretly triggers a duress alert.

[0192] 31. Temperature Sensor Triggers:

[0193] Using temperature sensors to detect unusual changes (e.g., the device being exposed to high heat or sudden cold) that could indicate a duress situation.

[0194] 32. Gaze Detection:

[0195] Activating duress mode if the device detects abnormal gaze patterns, such as the user not looking directly at the screen during authentication.

[0196] 33. Heartbeat or Stress Level Monitoring:

[0197] Using wearable devices or biometric sensors to detect abnormal heart rates or stress levels that could indicate distress and activate duress mode. 34. Haptic Feedback Signals:

[0198] Triggering duress mode by pressing a specific combination of physical buttons or areas on the device with varying pressure levels.

[0199] 35. Al Behavioral Analysis:

[0200] Activating duress mode automatically when the system detects unusual user behaviour, such as slow typing speed, hesitant actions, or erratic navigation in the app.

[0201] 36. Incorrect Login Attempts:

[0202] Entering the wrong password or PIN a specific number of times as a covert signal.

[0203] 37. Constant Face Scanning

[0204] If another person takes the device to perform transactions and the client is no longer using the device after being logged in to the application / website.

[0205] 38. Abnormal transactions

[0206] Abnormal amounts / account changes

[0207] 39. Preset transaction rules

[0208] For example: Location, time, transaction sizes, frequency. 40. Addition of Biometrics.

[0209] For example: adding a new "face" or "fingerprint" to access the financial platform.

[0210] Family Member / Partner Alternative Device Duress Mode

[0211] If a Family member / partner (or any other nominated person) is kidnapped and demands are made for the family to transfer funds, there can be 2 scenarios:

[0212] 1. If the family member / partner / associate etc. has the same banking app, the person that has been requested to perform the transfer of funds can tell the kidnappers that the person who is kidnapped is responsible for authentication of large transfers, this will activate the duress mode on the kidnapped persons phone, this will also cause the kidnappers to turn the phone on, should it have been turned off.

[0213] This can be done in the following manner:

[0214] Individual "Third Party Duress Contacts" should be preloaded on the client's profile.

[0215] The bank must immediately be notified that a Family member / partner is held under duress. This can be done by various means such as calling the bank, activating within the banking site or app by a link or any other means determined by the bank.

[0216] The kidnapped person's "Third Party Duress Contact" can be selected from within the client's profile thereby activating the "Family member / Partner Alternative Device Duress Mode".

[0217] A transaction authentication ("In app authentication" or "One Time Pin" etc, that has to match the sender's pin) or any other form of transaction authentication protocol is sent to the kidnapped persons phone, by entering / acknowledging the authentication protocol such as an in-app message or OTP, the kidnapped person's phone and banking app will enter duress mode.

[0218] The transactions will appear to have gone through but would be flagged as under duress.

[0219] An additional option would be that the first transaction authentication "fails" which still activates the duress security protocol but does not initiate the "transfer of funds". The kidnappers can be called a while later to be advised that the transaction failed and has to be authorized again. Alternatively, the kidnappers can be told that the first authorization on the kidnapped persons phone is to transfer funds from a "holding / investment" account and once the funds are in the "current account" a second authorization is required to transfer the funds to the Kidnappers account.

[0220] This will provide time for the security task force to be mobilized.

[0221] The Duress Security Protocol will be activated on the kidnapped person's phone or mobile device and / or the device authorizing the fund transfer:

[0222] 2. If the kidnapped person banks with a different bank and the family / partner / associate is contacted to make a payment, there can be a kidnapping hotline that can be called for that specific bank.

[0223] Alternatively, Individual "Third Party Duress Contacts" should be preloaded on the client's profile, these "Third Party Duress Contacts" should include links that can cross communicate with other banks and their apps / websites via push notifications, in app authentication or even just an acknowledgment of an OTP, or any other means that allows the kidnapped person's bank to be notified.

[0224] The kidnappers can be told that the kidnapped person is responsible for authenticating large transactions.

[0225] A transaction authentication ("In app authentication" or "One Time Pin") or any other form of transaction authentication protocol is sent to the kidnapped persons phone, by their bank. By entering / acknowledging the authentication protocol such as an in-app message or OTP, or any other means, the phone and banking app will enter duress mode.

[0226] This will activate the duress mode on the kidnapped persons phone, this will also cause the kidnappers to turn the phone on, should it have been turned off.

[0227] These messages can be sent directly from the kidnapped persons bank as a standalone message to activate duress mode or may be used in conjunction with the person's bank that is making the transfer, thereby activating the "Family member / Partner Alternative Device Duress Mode".

[0228] The transactions will appear to have gone through but would be flagged as under duress.

[0229] An additional option would be that the first transaction authentication "fails" which still activates the duress security protocol but does not initiate the "transfer of funds". The kidnappers can be called a while later to be advised that the transaction failed and has to be authorized again. Alternatively, the kidnappers can be told that the first authorization on the kidnapped persons phone is to transfer funds from a "holding / investment" account and once the funds are in the "current account" a second authorization is required to transfer the funds to the Kidnappers account. This will provide time for the security task force to be mobilized. The Duress Security Protocol will be activated on the kidnapped persons phone or mobile device and / or the device authorizing the fund transfer:

[0230] ATM or POS Functionality

[0231] An in app or push notification PIP may be required as an additional authentication method for logging in to a person's account on an ATM. Should an incorrect PIP or duress pin be used, then the duress mode will be triggered on the person's mobile phone.

[0232] Alternatively, should a person be forced to withdraw cash from an ATM or POS, an in-app duress pin, or incorrect PIP for the transaction could trigger a duress mode on the mobile phone of the person withdrawing funds.

[0233] The PIP may be required for every ATM or POS transaction or only when a person withdraws cash over a certain amount or consecutive withdrawals. Should an incorrect PIP or duress pin be used, then the duress profile may be activated on the ATM or POS and duress mode will be triggered on the mobile phone.

[0234] The Duress Security Protocol will be activated on the person's phone or mobile device:

[0235] Incorrect PIP or Duress Mode activation by mistake (Duress Reversal): If the incorrect PIP, duress PIN, or any other method used to activate duress mode is entered by mistake, and the client realizes the error, they should be able to notify the bank (e.g. Telephonically) to begin restoring normal account functionality through reactivation authentication.

[0236] The bank may verify the client's identity using a secure method such as a passcode, passphrase, or knowledge-based questions (KBQs). If the correct responses are provided, the account can be reactivated within a standard timeframe— typically 24 hours— or sooner / later based on the client's request or the bank's policy. Depending on the bank's procedures, this may restore either limited or full access to the account and its features.

[0237] In addition, the bank may offer an online or in-app option to reverse duress mode. This would require entry of a designated PIN, passphrase, PIP, or successful completion of KBQs, or other authentication mechanisms determined by the bank.

[0238] The live GPS location must still be available during this period in case the client has been forced to call the bank / cancel the duress mode. The bank can then ask them for a passcode, passphrase, or any other manner to determine if the client is still under duress or if an actual mistake was made. If the correct reactivation authentication (password / passphrase / predetermined answers to questions etc.) is given then the account may be reactivated in 24 hours, or any other time frame as requested by the client or as determined by the bank, this may enable immediate limited functionality and transactions or full functionality. The bank / security task force / team could also ascertain whether the client is still under duress based on the client's geolocation or account interaction.

[0239] Another option would be that if they require full access to their account sooner, they can go to their nearest branch to report in person that everything is ok, should this be a requirement of the bank.

[0240] Reactivation Duress

[0241] If a kidnapper is aware that the person they kidnapped has activated the Duress Mode on their Banking app or website, they may force the client / user to deactivate the Duress Mode, in a manner described above or any other way the bank may require.

[0242] Should the client / user be forced to cancel the Duress Mode with reactivation authentication, an alternative "panic" password / pin / PIP, giving incorrect answers to knowledge based questions, or simply an incorrect PIP can be given or used that doesn't match the registered reactivation authentication method, triggering the unchanged under duress profile, allowing full restoration of the electronic banking website or App, thereby creating the perception to the kidnappers that full functionality of the client's profile has been restored and the duress situation has been cancelled.

[0243] The Duress Security Protocol will remain active on the person's phone or mobile device.

[0244] Insurance

[0245] The bank may elect to provide the client with insurance to cover loss of funds under duress, to provide armed response when the duress profile is activated and also kidnap and ransom insurance including release and / or rescue negotiation and / orthe bank may opt to outsource the insurance to a third party.

[0246] Security / Ransom / Kidnap Task Force

[0247] The bank may provide the services of such as task force for rescuing the person held under duress.

[0248] The bank may opt to outsource such services.

[0249] Definitions

[0250] Any of the definitions below can be integrated into the FTP to prevent fraudulent access, as well as trigger a duress mode to safeguard funds and the client / user.

[0251] 1. Banking app or Financial Technology Platform (FTP) A Financial Technology Platform (Fintech Platform) is a digital system or application that facilitates financial transactions, services, or operations using technology. These platforms integrate various financial services, such as payments, trading, investing, banking, lending, and cryptocurrency transactions, often leveraging automation, artificial intelligence, blockchain, and data analytics to enhance efficiency, security, and user experience.

[0252] 2. Reactivation Authentication

[0253] Reactivation authentication refers to the security process required to verify a user's identity before reactivating a deactivated, suspended, or restricted account, particularly in high-risk industries like banking and fintech. This process ensures that only the legitimate account holder regains access, protecting against fraud and unauthorized use.

[0254] 3. Duress Mode

[0255] This is a security feature designed for situations where a user is forced to perform an action under threat, such as logging into a banking app, transferring funds, or unlocking a device. When activated, it allows the user to appear compliant while secretly triggering security protocols to prevent financial loss, alert authorities, request assistance from a security company or task force or delay transactions. 4. Client

[0256] A client refers to an individual or entity that uses the services offered by a bank or financial technology platform. The client interacts with the bank through various channels, such as mobile financial technology apps, online financial technology platforms, payment gateways, or physical branches or ATM's.

[0257] Key points about a client in banking applications:

[0258] (a) Personal or Business: A client can be an individual (personal banking) or a business (corporate banking).

[0259] (b) Account Holder: Typically, a client has one or more accounts with the bank, such as a checking account, savings account, or loan.

[0260] (c) Transaction Initiator: The client initiates actions such as transferring funds, making deposits, checking balances, or applying for loans.

[0261] (d) Authentication: Clients are authenticated using secure methods like passwords, PINs, biometric recognition, two-factor authentication or multi-factor authentication (MFA)to ensure access to their accounts and transactions are secure.

[0262] A Client may authorise a User: A User refers to any individual or entity that interacts with the financial technology platform system or application. A user can be a client (account holder) or someone who has access to the system for specific roles, such as employees, administrators, or third-party service providers.

[0263] 5. Authentication

[0264] The process of verifying the identity of a client before allowing access to their financial technology platform account or application.

[0265] Examples:

[0266] (a) Single Factor Authentication (SFA): A simple method using something the user knows (e.g., a password).

[0267] (b) Two-Factor Authentication (2FA): A security system that requires two forms of identification, such as a password and a code sent to the user's phone.

[0268] (c) Biometric Authentication: Verification using physical features like fingerprints, face recognition, or retina scans.

[0269] (d) Multi-Factor Authentication (MFA): A security system that requires more than two forms of identification or codes sent to users' phone or another nominated device, token devices, biometric scans, or authentication apps.

[0270] 5.1. Password-Based Authentication Description: The most basic form of authentication where a user enters a unique username and / or password to access their account, Including screen patterns.

[0271] 5.2. Multi-Factor Authentication (MFA)

[0272] Description: Adds additional layers of security by requiring two or more verification factors. MFA typically combines something the user knows (password), something they have (phone, security token), or something they are (biometric data).

[0273] Examples:

[0274] (a) Password + One-Time Password (OTP): A password combined with a temporary code sent to the user's phone.

[0275] (b) Password + Biometric Authentication: A password and fingerprint recognition.

[0276] (c) Risk activities (e.g., transferring large sums, changing account details).

[0277] 5.3. Biometric Authentication

[0278] Description: Uses unique physical characteristics of a user to authenticate their identity. Common biometrics include fingerprints, facial recognition, heart rate and voice recognition.

[0279] Examples: (a) Fingerprint Scanning: A user's fingerprint is captured and compared to stored data.

[0280] (b) Face Recognition: A camera scans the user's face and compares it to stored images.

[0281] (c) Voice Recognition: Analyses a user's voice pattern to verify identity.

[0282] 5.4. Two-Factor Authentication (2FA)

[0283] Description: A subset of MFA where only two authentication factors are used. Typically, this involves something the user knows (password) and something the user has (an OTP sent to their phone or generated by an app).

[0284] Examples:

[0285] (a) Password + OTP: The user enters their password and then enters a temporary code sent to their phone via SMS or generated in app or by an authenticator app.

[0286] (b) Password + Push Notification: A prompt is sent to the user's phone to approve or deny the login attempt.

[0287] (c) Strengths: Simple and highly effective for securing online accounts.

[0288] 5.5. Token-Based Authentication Description: A security process in which a user is given a physical or digital token to authenticate their identity.

[0289] Examples:

[0290] (a) Hardware Token: A small device that generates a one-time password (OTP) for each login attempt.

[0291] (b) Software Token: An app on the user's device that generates a timesensitive code for authentication

[0292] 5.6. SMS / Email-Based Authentication

[0293] Description: The user receives a one-time passcode (OTP) via SMS or email to authenticate their login attempt.

[0294] 5.7. Risk-Based Authentication (RBA)

[0295] Description: This adaptive authentication method assesses the risk level of a transaction or login attempt based on several factors, such as location, device, behaviour, or transaction size. If the risk is deemed high, additional authentication steps are triggered.

[0296] Examples: If a user logs in from an unusual location, the system may prompt for additional verification (e.g., answering security questions or providing an OTP).

[0297] 5.8. Password less Authentication

[0298] Description: A method that allows users to log in without using a password. Instead, users authenticate using alternative factors such as biometric data or one-time codes.

[0299] Examples:

[0300] (a) Email Magic Link: A user receives a secure link in their email that they click to authenticate.

[0301] (b) Biometric Authentication: Logging in using only facial recognition or fingerprint scan.

[0302] 5.9. Behavioral Biometrics

[0303] Description: A method of authentication that uses patterns of behaviour (e.g., typing speed, mouse movements, device handling, facial expressions) to verify the identity of the user.

[0304] Examples: Monitoring how a user types or interacts with the application can help establish a unique user profile.

[0305] 5.10. Location-Based Authentication

[0306] Description: This method uses the geographic location of the user, typically by GPS or IP address, to verify that the login attempt is coming from a recognized or authorized location.

[0307] Examples:

[0308] A bank might only allow logins from certain geographic regions or flag logins from unusual locations.

[0309] 5.11. Cryptographic Authentication

[0310] Description: Uses cryptographic keys to authenticate users, ensuring that only authorized parties can access a system or transaction.

[0311] Examples:

[0312] (a) Public / Private Key Authentication: A user holds a private key, and the bank or application holds a corresponding public key. To authenticate, the user signs a piece of data with their private key, which the system can verify using the public key. (b) Digital Certificates: Used in SSL / TLS protocols, these certificates provide a cryptographic way to authenticate users and devices, often used in secure banking websites.

[0313] 5.12. One-Time Password (OTP) via Hardware Devices

[0314] Description: A physical device (like a key fob) generates a one-time password that the user enters as part of the authentication process.

[0315] Examples:

[0316] (a) RSA SecurlD: A hardware token that generates a time-based code (typically every 30 seconds) for secure access.

[0317] (b) Smart Cards: Similar to hardware tokens but used in conjunction with a card reader.

[0318] 5.13. Single Sign-On (SSO)

[0319] Description: Allows users to authenticate once and gain access to multiple applications or systems without needing to log in separately to each.

[0320] Examples: (a) OAuth: A protocol that allows users to authenticate using their credentials from another trusted service (e.g., Google, Facebook, or a corporate identity provider).

[0321] (b) OpenlD Connect: A simple identity layer on top of OAuth 2.0, commonly used for web-based applications.

[0322] 5.14. Challenge Questions / Knowledge-Based Authentication (KBA)

[0323] Description: A user answers predefined challenge questions that only they should know the answers to (e.g., mother's maiden name, the name of your first pet).

[0324] Examples:

[0325] Used as a secondary verification step when a user forgets their password or is performing high-risk activities.

[0326] 5.15. Hardware Security Modules (HSM) Authentication

[0327] Description: A physical device used to generate, store, and manage cryptographic keys and authenticate users securely in high-security environments.

[0328] Examples: Banks and financial institutions may use HSMs to handle sensitive data, encryption, and authentication processes.

[0329] 5.16. Device-Based Authentication

[0330] Description: Uses the device the user is logging in from as an authentication factor. This method can verify that the user is on a trusted device, such as a registered mobile phone or laptop.

[0331] Examples:

[0332] (a) Device Fingerprinting: Identifies and tracks devices based on hardware characteristics (e.g., IP address, browser version, screen resolution).

[0333] (b) Trusted Devices: Users can designate certain devices (like their personal phone or laptop) as "trusted" and bypass some authentication steps when logging in from those devices.

[0334] 5.17. Social Login Authentication

[0335] Description: Allows users to authenticate via their social media or third-party accounts, such as Facebook, Google, or Linkedln.

[0336] Examples: OAuth 2.0: Allows users to sign in using existing credentials from another service, such as their Google account.

[0337] 5.18. Passive Authentication (Continuous Authentication)

[0338] Description: Authentication that happens continuously in the background, without requiring the user to do anything, based on their actions and behaviour while interacting with the app.

[0339] Examples:

[0340] (a) Behavioral Biometrics: Monitors how a user interacts with their device (e.g., typing speed, mouse movements) to continuously verify their identity during a session.

[0341] (b) Device and Location Tracking: Continuously checks if the user is accessing the service from a trusted device or location.

[0342] 5.19. Time-Based Authentication (Time-Window Authentication)

[0343] Description: Uses a time window to determine if the authentication request is valid. A user's login attempt is valid only during a predefined time period (e.g., an OTP is valid for a certain number of minutes).

[0344] Examples: Time-Limited OTP: One-time passwords that expire after a certain period (e.g., 30 seconds or a few minutes).

[0345] 5.20. IP Geolocation Authentication

[0346] Description: Uses the geographic location of a user's IP address to verify their login attempt.

[0347] Examples:

[0348] If a user attempts to log in from an unusual geographic location (e.g., a different country), the bank might require additional verification.

[0349] 5.21. Quantum Cryptography Authentication

[0350] Description: Quantum cryptography leverages the principles of quantum mechanics to create theoretically unbreakable encryption methods for securing communications and verifying identities.

[0351] Examples:

[0352] Quantum Key Distribution (QKD): A method of securely transmitting encryption keys that relies on the laws of quantum physics to ensure that any eavesdropping attempt would be detected.

[0353] 5.22. Contextual Authentication Description: An authentication method that adjusts its security requirements based on the context of the login attempt. For example, it may require additional authentication if the login happens from an unusual location, device, or at a strange time.

[0354] Examples:

[0355] If a user typically logs in during work hours and then tries to log in at midnight from a new device, the system might trigger a higher level of authentication (like an OTP or biometric scan).

[0356] 5.23. Voiceprints (Voice Biometrics)

[0357] Description: A type of biometric authentication based on the unique characteristics of a user's voice, including pitch, tone, and cadence.

[0358] Examples:

[0359] Voice Recognition: Systems like Amazon Alexa and Google Assistant use voice biometrics for voice-based authentication in banking apps.

[0360] 5.24. Smartphone Push Notifications (for Authentication) Description: Push notifications are sent to a user's smartphone when a login attempt is made, requiring them to approve or deny the request before access is granted.

[0361] Examples:

[0362] Push Authentication: Mobile apps can send a prompt to the user's phone, asking for approval of the login request, effectively turning the phone into a second factor of authentication.

[0363] 5.25. Eye Scan (Iris Recognition)

[0364] Description: A biometric authentication method that analyses the unique patterns in a person's iris (the coloured part of the eye) for identity verification.

[0365] Examples:

[0366] (a) Used for high-security applications in various sectors, including banking, healthcare, and government.

[0367] (b) Strengths: Extremely difficult to spoof due to the uniqueness of the iris, providing an extremely high level of security.

[0368] 5.26. Geofencing Authentication Description: This method uses GPS or Wi-Fi data to track a user's physical location and restrict access to certain banking features based on whether the user is within a predefined geographic area (e.g., a bank branch, country, or city).

[0369] Examples:

[0370] A bank could require additional verification (e.g., OTP or biometric scan) if a user tries to log in from a different country, indicating a potential fraud risk.

[0371] 5.27. Steganographic Authentication

[0372] Description: A more unusual and emerging concept, this method hides authentication data (such as a secret key or password) within another piece of information, such as an image, sound, or video.

[0373] Examples:

[0374] A user could receive a seemingly normal image file, but embedded within it is a code that, when extracted, serves as part of their authentication process.

[0375] 5.28. Blockchain-Based Authentication

[0376] Description: Blockchain technology could be used to store and manage user authentication information securely in a decentralized manner.

[0377] Examples: Users could authenticate with banks or services via a blockchain-based ID that is stored securely on the blockchain and could be accessed via cryptographic keys.

[0378] 5.29. Heart Rate (Cardiac) Biometrics

[0379] Description: An emerging biometric authentication method that uses a person's unique cardiac signals, such as heartbeat rhythms or electrocardiogram (ECG) patterns, to verify their identity.

[0380] Examples:

[0381] A user could authenticate by holding their hand on a specialized sensor or the use of a smart watch or device that detects heart patterns.

[0382] 5.30. Motion Pattern Authentication

[0383] Description: Tracks and analyses how a user physically interacts with a device (e.g., typing, swiping, holding) to verify their identity based on unique motion patterns.

[0384] Examples:

[0385] Similar to behavioural biometrics but focused on how the user moves or interacts with a device.

[0386] 5.31. Finger Vein Authentication Description: Uses near-infrared light to capture the unique vein patterns in a person's finger to authenticate their identity.

[0387] Examples:

[0388] A scanner placed on the finger identifies the vein pattern and compares it to a stored reference.

[0389] 5.32. Behavioral Biometrics

[0390] Description: Analyses patterns in user behaviour to identify and authenticate them. This could involve assessing how the user types, moves the mouse, or navigates through the app.

[0391] Examples:

[0392] Analysing typing speed, key press patterns, and mouse movements to continuously verify identity.

[0393] 5.33. Dynamic Signature Authentication

[0394] Description: A behavioural biometric method that uses the user's unique way of signing their name to authenticate them.

[0395] Examples: When a user writes or signs their name on a touch screen, the speed, pressure, and motion are measured to create a dynamic signature profile.

[0396] 5.34. DNA-Based Authentication

[0397] Description: A highly advanced form of biometric authentication that uses a user's DNA to verify their identity.

[0398] Examples:

[0399] Collecting a DNA sample (like saliva) or using a DNA-based device to match genetic material against a database.

[0400] 5.35. Skin Conductance (Galvanic Skin Response)

[0401] Description: Measures the electrical conductance of the skin, which changes with stress, emotions, or arousal, to verify the identity of the user.

[0402] Examples:

[0403] A sensor detects changes in the skin's conductivity during user interaction, which can serve as an authentication factor.

[0404] 5.36. Touchless Fingerprint Scanning Description: Similar to traditional fingerprint scanning but uses a contactless sensor, which scans the finger from a distance (using optical or ultrasonic technology).

[0405] Examples:

[0406] Used in newer mobile devices and high-end security systems for a more hygienic and efficient fingerprint scan.

[0407] 5.37. Location-Based Authentication

[0408] Description: Uses the user's physical location (determined via GPS, IP address, or Wi-Fi) to verify their identity and control access to sensitive financial data or transactions.

[0409] Examples:

[0410] Only allowing banking transactions from recognized locations (e.g., a user's home country or specific geographic area).

[0411] 5.38. Time-of-Use Authentication

[0412] Description: Uses the time of day or specific times of use to verify if the login attempts or transaction request is consistent with the user's usual behaviour.

[0413] Examples: If a user typically logs in during business hours, any attempt to access the account at an unusual hour may trigger an additional verification step.

[0414] 5.39. Artificial Intelligence (Al)-Powered Authentication

[0415] Description: Al and machine learning algorithms can continuously analyse a user's behaviour, biometrics, and other data points to authenticate users in realtime.

[0416] Examples:

[0417] Machine learning models that analyse patterns in typing, mouse movement, or transaction history to detect anomalies or authenticate users.

[0418] 5.40. Social Engineering-Based Authentication (Risk-Based)

[0419] Description: Leverages social engineering and risk analysis to assess the likelihood of fraud based on the user's behaviour, interactions, and communication patterns.

[0420] Examples:

[0421] If a user makes a high-value transaction or accesses their account from an unfamiliar device, the system might flag the transaction for manual review or prompt additional verification steps. 5.41. Motion-Based Authentication (Gyroscope / Accelerometer)

[0422] Description: Uses the gyroscope or accelerometer built into devices like smartphones to analyse how the user physically moves or tilts the device as part of the authentication process.

[0423] Examples:

[0424] Detecting how a user tilts their phone during login to create a unique motion signature.

[0425] 5.42. Email or Message Token Authentication (Email-based)

[0426] Description: Sends a one-time token or verification link to the user's registered email address, which they must enter to complete the authentication process.

[0427] Examples:

[0428] Commonly used for password resets or verifying new device logins.

[0429] 5.43. Cognitive Behavioral Authentication

[0430] Description: This method uses the cognitive responses of users to verify their identity. It involves monitoring how a user interacts with their environment, such as how they react to prompts, questions, or interface elements.

[0431] Examples: A user might be asked to perform a task or answer questions in a specific manner that matches their previous behaviour.

[0432] 5.44. Motion Detection for Authentication (Body Movement)

[0433] Description: Leverages the user's unique body movements, such as walking patterns or posture, to authenticate their identity.

[0434] Examples:

[0435] Systems that track how a user walks using sensors on a device, or camera-based systems that analyse gait (the way a person walks).

[0436] 5.45. Al-Powered Face Recognition (Continuous Facial Monitoring)

[0437] Description: Unlike traditional face recognition (which only authenticates at the login stage), this method continuously monitors a user's face throughout their session.

[0438] Examples:

[0439] Used in high-security applications where users are constantly authenticated as long as they are interacting with the system (e.g., for access to sensitive financial data or transactions).

[0440] 5.46. Keystroke Dynamic Analysis Description: Keystroke dynamics analyse the rhythm, speed, and pattern in which a user types on a keyboard or touch screen. This can help to authenticate users based on how they type.

[0441] Examples:

[0442] (a) Measuring typing speed, the time spent between keystrokes, and the pressure applied (in some cases).

[0443] (b) Strengths: Continuous authentication while the user interacts with a system, offering an additional layer of security.

[0444] 5.47. Social Media Authentication

[0445] Description: Uses a user's social media profile as a way to authenticate their identity. This can involve logging in using a service like Facebook, Google, or Linkedln.

[0446] Examples:

[0447] Banks could allow users to authenticate by connecting their social media account (e.g., Facebook, Linkedln) to their banking app, providing a secondary authentication factor.

[0448] 5.48. Cryptographic Tokens (Hardware and Software Tokens) Description: Uses hardware (physical token generators) or software applications that produce a time-based one-time password (TOTP) to authenticate users.

[0449] Examples:

[0450] A hardware token like RSA SecurlD or an app like Google Authenticator generates a new code every 30 seconds.

[0451] 5.49. RFID / N FC-Based Authentication

[0452] Description: Uses Radio Frequency Identification (RFID) or Near-Field Communication (NFC) technology to authenticate a user by proximity or through a physical RFID card.

[0453] Examples:

[0454] Banks could issue an NFC-enabled card to the user, which can be tapped on a terminal to authenticate and access banking services.

[0455] 5.50. Smartwatch-Based Authentication

[0456] Description: Leverages data from wearable devices, like a smartwatch, to verify a user's identity based on proximity or a biometric sensor in the device.

[0457] Examples: Smartwatches can use biometric sensors (like heart rate) to authenticate users when they approach their device or bank terminal.

[0458] 5.51. Eye Movement Authentication (Gaze-Based)

[0459] Description: This method analyses the unique pattern of eye movement or gaze direction to authenticate users.

[0460] Examples:

[0461] By tracking the way, a person moves their eyes to interact with their banking application or service, systems can identify patterns unique to each individual.

[0462] 5.52. Ultrasound Authentication

[0463] Description: Uses sound waves that are undetectable to the human ear (ultrasound) to verify identity by detecting a user's presence or authentication token.

[0464] Examples:

[0465] Banks could use ultrasound signals transmitted by an app on the user's phone and received by a device to authenticate the user in proximity.

[0466] 5.53. Biometric Liveness Detection Description: Liveness detection is a biometric technique that ensures the biometric sample being provided (e.g., fingerprint, face scan) is coming from a live person and not from a photo, video, or artificial replica.

[0467] Examples:

[0468] During facial recognition, the system can check for signs of liveness, such as blinking, facial movement, or 3D depth, to verify that the scan is coming from a real person.

[0469] The above authentication methods can used individually or in combination and can be described as a Personal Identification Protocol (PIP).

[0470] 6. Account

[0471] A record maintained by a bank that shows the financial transactions of a client, including deposits, withdrawals, and balances.

[0472] Types:

[0473] (a) Checking Account: An account for everyday financial transactions like paying bills, writing checks, and withdrawing cash.

[0474] (b) Savings Account: An account intended for saving money, often earning interest over time. (c) Loan Account: An account where the bank tracks the repayment of a loan or mortgage.

[0475] (d) Credit Account: An account that allows clients to borrow funds up to a certain limit and repay over time (e.g., a credit card account).

[0476] 7. Transaction

[0477] Any action or operation carried out by a client that affects their bank account, such as a transfer, payment, deposit, or withdrawal.

[0478] Examples:

[0479] (a) Deposit: Adding money to a bank account.

[0480] (b) Withdrawal: Taking money out of a bank account.

[0481] (c) Transfer: Moving funds between accounts or to other individuals or businesses.

[0482] 8. Payment Gateway

[0483] A technology that processes payment transactions in banking applications, especially when making online or mobile payments.

[0484] Function: The payment gateway securely encrypts and transmits payment information from the client to the bank or financial institution, facilitating electronic payments. Example: PayPal, Stripe, or the bank's proprietary system used in online banking apps.

[0485] 9. Mobile Banking

[0486] A service provided by banks that allows clients to conduct financial transactions and access their accounts using a mobile device or application.

[0487] Function examples:

[0488] (a) Checking balances.

[0489] (b)Transferring funds.

[0490] (c) Paying bills.

[0491] (d) Depositing checks via mobile image capture.

[0492] 10. Encryption

[0493] The process of converting data into a secure format that can only be read by authorized parties, typically used to protect sensitive information like bank account details.

[0494] Purpose: Ensures that financial transactions and client data are safe from unauthorized access during transmission (e.g., when transferring funds via mobile banking). Example: SSL (Secure Socket Layer) encryption used in online banking sites. 11. API (Application Programming Interface)

[0495] A set of protocols and tools that allow different banking systems, apps, or services to communicate with each other.

[0496] Example: A third-party payment processor using an API to access a client's bank account to facilitate a transaction, or connecting a bank's core system with a mobile app.

[0497] 12. Fraud Detection

[0498] Systems and methods used by banks to identify and prevent fraudulent activities within banking applications.

[0499] Techniques:

[0500] (a) Behavioral Analytics: Analysing patterns of client behaviour to detect anomalies (e.g., unusual login times or transaction locations).

[0501] (b) Machine Learning: Using algorithms to predict fraudulent transactions based on historical data.

[0502] (c) Real-Time Alerts: Sending notifications to clients if suspicious activities are detected.

[0503] 13. Biometric Verification The use of unique biological traits to authenticate a client's identity for secure banking transactions.

[0504] Examples:

[0505] (a) Fingerprint Scanning: Using the client's fingerprint to verify their identity.

[0506] (b) Facial Recognition: Analysing the client's face for verification.

[0507] (c) Voice Recognition: Using a client's voice to authenticate access to their account.

[0508] 14. Loan Application

[0509] A formal request by a client to borrow money from a bank, which is typically reviewed based on creditworthiness and other criteria.

[0510] 15. Transactional Application

[0511] Any Transaction security for online banking, or any other fund related website or app. These could be sharing transacting apps or websites, cryptocurrency apps and websites.

[0512] 16. GPS Location:

[0513] Location based on global positioning system 17. Cell tower triangulation, Wi-Fi signals

[0514] Location based on radio signals originating from land based structures

[0515] 18. Delayed and Reversible Transactions

[0516] The transactions flagged as "under duress" can be delayed or can be reversible

[0517] 19. Communication Integration

[0518] A covert communication system where users can send distress messages through the app by using hidden gestures or sequences (e.g., pressing a particular key combination). The app could automatically send out a predefined SMS or email to emergency contacts or law enforcement without showing any signs on the phone. This can also be used activate the Duress or Silent Duress Profile

[0519] 20. Time-Based Locks

[0520] In high-risk situations, users could activate a "safe mode" where they pre-define that the app is inaccessible for a certain period, even with valid credentials. This could also be triggered under duress, so that the attacker believes the bank is down temporarily.

[0521] 21. Self-Destruct Mode A feature that, when activated, completely wipes or locks the app for a fixed period. This can prevent any access to sensitive information if the user is forced to hand over the device.

[0522] 22. Pre-Defined Escape Triggers

[0523] Enable users to set up pre-defined scenarios where the system will automatically shut down access, send alerts, and notify authorities if the wrong combination of credentials (e.g., incorrect passwords or abnormal transaction types) is entered repeatedly.

[0524] 23. Post-Duress Action Log

[0525] After a duress situation is handled, provide users with an option to view detailed logs of what actions were taken (including false transactions). This can help them track any issues and report to authorities or fraud departments.

[0526] 24. Integration with Smart Devices

[0527] Integration with loT Devices: The app could connect with smart home devices (e.g., lights, cameras) or car systems that trigger security protocols. For example, a smart home camera could activate, or a car GPS could log the exact location if duress mode is initiated on the banking app. The Bank and Security Task Force will have access to these smart devices once activated. 25. Security Task Force

[0528] A specialized group / company formed to address and respond to kidnapping incidents, particularly in high-stakes situations such as those involving individuals, family members, or valuable assets. The STF's focus is on prevention, response, and recovery in cases where kidnapping or hostage situations occur.

[0529] 26. Emergency Communication Links

[0530] Disguised Communication Options: Implement a discreet method for the user to send emergency messages to the bank, authorities, or pre-defined contacts through the app without raising suspicion. For instance, typing a specific word or sequence in a chat window or transferring a "hidden" amount (e.g., RO.00) could trigger a distress signal.

[0531] Silent Alarms: Users could trigger silent alarms through specific gestures within the app or on their device, such as shaking the phone in a certain way or holding down the power button for an extended period.

[0532] This can also activate the Silent Duress Profile

[0533] 27. Virtual Environment Monitoring

[0534] Background monitoring of sounds to "listen" for specific words set to trigger the

[0535] Silent Duress Profile. 28. Fake App Lock

[0536] Fake Out: Upon detecting suspicious behaviour, the banking app could mimic an app malfunction or connection issue. This would prevent the criminal from accessing the account, while alerting the bank to monitor the situation. An "App crash" could happen deliberately, confusing the attacker but allowing the bank to intervene.

[0537] This could allow the Security Task Force to mobilise in case the client / user is moved to a new location after the funds have been transferred and the possibility that the phone or mobile device has been discarded.

[0538] 29. Dynamic Profile Masking

[0539] Rather than showing only a single "under duress" profile, the app could randomly generate multiple decoy profiles with different balances or transaction histories. This would make it harder for attackers to identify whether they are in a real account or a fake one, keeping them engaged long enough for authorities to respond.

[0540] 30. Post-Duress Tracking

[0541] The system could continue monitoring for a set period after the duress mode is triggered to track further suspicious behaviour. This includes: (a) Device access logs: Monitoring attempts to access the app from another device, location, or using stolen credentials.

[0542] (b) Social Engineering Detection: Watching for common fraud patterns like phishing attempts after the incident.

[0543] 31. On-the-Fly Account Migration

[0544] Under duress, instead of showing reduced balances, the app could silently migrate all of the user's assets to a hidden account with restricted access, while showing the criminal a decoy profile. This would ensure that the funds are safe even if the attacker succeeds in initiating a transaction.

[0545] 32. Multi-Account Safety Mechanism

[0546] Many users hold multiple accounts (e.g., personal and business accounts). The app could automatically divert transactions between these accounts or within the banking ecosystem itself. For example, if someone tries to transfer R50,000, the app could move the funds between the user's own linked accounts, simulating a successful transaction to the criminal while preserving the user's funds.

[0547] 33. Blockchain for Transaction Traceability Blockchain technology is used to create an unalterable record of duress transactions. This could ensure that flagged transactions are easier to reverse while maintaining the integrity of the account's data for security audits.

[0548] 34. Smart Contract Integration

[0549] Smart contracts are automatically triggered when duress transactions occur. These contracts could handle fund reversals, sending alerts, and freezing accounts without human intervention, thus automating the response.

[0550] 35. Security as a Service (SaaS)

[0551] A cloud-based model where third-party providers deliver outsourced security solutions to protect an organization's data, systems, and networks.

[0552] 36. Non-Mobile Platforms

[0553] Any digital platforms, such as wearable devices, ATM machines, and browser extensions

[0554] 37. Duress Reversing

[0555] Normal Profile functionality is restored:

[0556] Example: Trusted Contact Verification: If the app detects that the user is under duress, it could automatically reach out to a trusted contact to verify the user's safety. Only after receiving confirmation that the client / user is safe, from the trusted contact, would full account functionality be restored.

[0557] 38. Time-Limited Duress Mode

[0558] Time-Lock Activation: Users / Clients could set a specific window of time (e.g., a particular hour of the day or day of the week) where duress mode is active automatically. This could be useful for high-risk situations where users anticipate potential threats (e.g., during large cash withdrawals or sensitive transactions).

[0559] 39. Al-Generated Responses

[0560] Conversational Al: If an attacker engages with customer service during a duress event, an Al-powered chatbot could handle the conversation using preprogrammed scripts to buy time and gather more information. For example, the Al could simulate a routine inquiry process, keeping the attacker occupied while alerting the bank's fraud team.

[0561] 40. Multiple Persona Profiles

[0562] Multiple Decoy Personas: The app could create several decoy profiles with different financial situations and transaction histories. This makes it harder for criminals to identify which is the real one. The different personas could mimic real-life profiles such as a student account, a business account, or a low-balance account.

[0563] 41. Decentralized Authentication

[0564] Blockchain Authentication: The user's identity verification is split across multiple distributed nodes. This way, even if the attacker forces entry into the banking app, their actions would need to pass through multiple layers of authentication distributed across the network, which could raise flags.

[0565] 42. Digital Identity and Wallet Protection

[0566] Digital Identity and Wallet Protection refers to the safeguarding of a user's personal digital credentials and financial assets stored within digital wallets. This includes protecting sensitive data such as identification documents, authentication credentials, payment information, and cryptographic keys from unauthorized access, theft, or manipulation.

[0567] Key components typically include:

[0568] (a) Identity Verification: Ensuring the user is who they claim to be using biometrics, multifactor authentication (MFA), or cryptographic certificates. (b) Encryption and Secure Storage: Encrypting personal and financial data within the wallet to prevent interception or tampering.

[0569] (c) Access Controls: Restricting wallet access through secure login protocols like PINs, passwords, biometrics, or device-based authentication.

[0570] (d) Transaction Monitoring: Continuously analysing transaction behaviour for fraud detection or suspicious activity.

[0571] (e) Backup and Recovery Options: Allowing users to securely recover access in case of device loss or compromise.

[0572] This protection is essential in modern financial platforms to maintain trust, reduce fraud risk, and ensure compliance with data security standards.

[0573] The Financial Technology Platform / Bank / client can decide to use the security application in various configurations, an example would be requiring the PIP at log in stage only at selected times / locations, however the in app authentication PIP will always be active (based on in app authentication parameters) to ensure there is always a level of protection.

[0574] New Definitions

[0575] Any of the definitions below can be integrated into the FTP to prevent fraudulent access, as well as trigger a duress mode to safeguard funds and the client / user. 1. Duress Mode

[0576] The mobile device, tablet, laptop, desktop or any device used to transact on financial technology platforms (e.g. banking) enters a specific mode that triggers a duress security protocol and or profile.

[0577] 2. Duress security protocol

[0578] Certain actions and functions are activated on the mobile device, tablet, laptop, desktop or any other device used to transact on financial technology platforms, to enable the locating, tracking, monitoring and interaction with or of such electronic device. This will allow a security task force / kidnap and ransom task force to locate and recover the person under duress. Transactions or interactions will be flagged as fraudulent.

[0579] 3. Duress Profile

[0580] A Normal Profile (Unchanged), with transactions or interactions flagged as under duress.

[0581] Or a decoy profile with reduced accounts, balances and functionality.

[0582] Allowing the user to complete transactions as if normal but flagging those transactions internally to the financial technology platform (e.g. bank). A Duress Profile allows users to maintain a secondary, covert account mode for use under coercion or threat. When activated, this profile enables users to appear compliant while triggering silent security measures, preventing or limiting financial loss, unauthorized access, or harm.

[0583] 4. Silent Duress Profile

[0584] Normal financial technology platform (e.g. banking) profile is active, but any transactions or interaction on the profile is flagged as under duress and will trigger the duress mode.

[0585] Example: Should the client / user feel they are in grave danger, an alternative / agreed / incorrect password / pin or other means of authentication can be given, which activates the silent duress functionality, allowing full functionality of the financial technology platform. This profile would be activated after a successful normal login, and while within the financial technology platform or application a transactional flag triggers the profile activation.

[0586] 5. Family Member / Partner Alternative Device Duress

[0587] An alternative device is triggered to enter duress mode

[0588] 6. Customizable "Duress Profile" Settings Allow users to set their own preferences for what shows up in the duress profile (e.g., certain account types, balances, or specific features like loan approvals could be hidden or faked). This customizability gives users flexibility to make the decoy account more convincing.

[0589] 7. Personal identification Protocol (PIP)

[0590] This can be any form of identification such as a PIN, Password, Biometrics, Passphrase or combination thereof or any other means of identifying and authenticating an individual as described in the definition of authentication.

[0591] 8. Multiple-Level Authentication

[0592] In addition to the PIP and duress profile, this is a step-up authentication for high- risk transactions. Even after the duress profile is activated, sensitive actions (e.g., large transfers) could require additional biometric authentication or the use of a separate physical token, or third-party authorization.

[0593] 9. Al-Driven Threat Detection

[0594] Anomaly Detection with Al: Implement Al to monitor user behaviour patterns and detect deviations in real-time. For example, unusual transaction patterns or login attempts from unfamiliar locations could trigger the duress mode automatically. Facial Recognition Analysis: If the app uses facial recognition, Al could analyse the user's facial expressions or emotions for signs of distress (e.g., using subtle cues like stress or fear in their face).

[0595] Voice Analysis: If voice control is integrated into the financial technology platform app, Al-driven voice analysis could detect distress in the user's tone during verbal interactions with the system or background sound monitoring.

[0596] 10. Voice-Activated Duress Code

[0597] Allow the user to activate the duress mode using a pre-defined voice command or phrase. This would be especially useful when physically forced to use the financial technology platform app under duress. For instance, a user could say "I forgot my password" or any innocuous phrase to trigger the decoy profile without alerting attackers.

[0598] 11. In App Authentication Duress Activation

[0599] If you are in your normal financial technology platform or banking app, a transaction or action may require authentication and an additional pin, alternative biometric, or any other PIP. If the incorrect or predetermined duress pin / PIP is entered, duress mode is activated, and interactions and fund transfers are flagged. There will be no requirement for a false profile in this scenario. 12. Multi-Party Duress Mode

[0600] Shared Financial Technology Platform (e.g., Bank) Accounts: In joint accounts, if one account holder activates the duress mode, the other party could be notified and have the ability to lock, monitor or activate Silent Duress mode on the account. This could be useful for family or business partnerships where more than one person has access to the same account.

[0601] 13. Fake "Low Account Balance" Feature

[0602] Under duress, instead of just showing reduced balances, the app could trigger an automatic message stating that the user's account is "under investigation" or "temporarily restricted due to low balance" after initiating transfers. This would prevent attackers from continuing to push for transactions, while maintaining the illusion of normalcy.

[0603] 14. Physical Gesture-Based Triggers

[0604] Tactile Passwords: A physical action (e.g., holding down a volume button, or swiping the screen in a particular pattern) that triggers duress mode. This gesture could be subtle enough not to alert the attacker but would activate the decoy account and alert the Financial Technology Platform (e.g. Bank). Phone Movement Detection: The app could use the phone's accelerometer to detect patterns of shaking or force (indicative of stress or physical struggle) and automatically trigger duress mode.

[0605] 15. Proactive Al Monitoring & Pre-emptive Alerts

[0606] Predictive Al: Use machine learning models to analyse historical transaction data to predict potential fraud or duress situations before they occur. For example, the app could automatically raise security levels or even pre-emptively trigger duress alerts and actions when suspicious activities are detected.

[0607] Proactive Notification to Authorities: The app could monitor communication patterns, web browsing, and SMS logs for signs of threats (with user consent) and alert authorities or the Financial Technology Platform (e.g. Bank) in the case of a potential kidnapping or extortion scenario.

[0608] 16. Time-Delayed Transfers

[0609] Inbuilt Delay Mechanism: Under duress, any transaction initiated would automatically have a built-in delay (even for so-called "instant transfers"). The app could show that the funds have been deducted, and the transaction completed, but the real transfer would only process after a set time, allowing the Financial Technology Platform (e.g. Bank) to freeze or reverse it before it goes through.

[0610] 17. Honeypot Accounts

[0611] Under Duress mode, any external banking details are not used but seems to have been used for the transfer process, alternative predetermined accounts are used where the funds are transferred to.

[0612] The criminal's account is flagged and blocked, or the funds could appear to have been transferred but the entry is fake. The criminal is then requested to come into the bank to re-activate their account and can then be arrested.

[0613] 18. Integrated Financial Risk Score

[0614] Dynamic Risk Scoring: A financial risk score based on user behaviour, device security, location, and transaction patterns. If the score drops below a certain threshold (e.g., frequent risky behaviour or travel to high-risk regions), the app could automatically lock certain functionalities and activate duress detection mechanisms and even activate duress mode and profiles if needed.

[0615] 19. Adaptive Security Layers

[0616] Adaptive and dynamic security layers that adjust based on user behaviour, location, device status, and other contextual factors. 20. Transactional Flag

[0617] A Transactional Flag is a predefined condition or rule within a financial or digital system that automatically identifies, marks, or responds to specific types of transactions based on certain criteria. These flags are used to detect anomalies, enforce security protocols, or trigger additional actions such as verification, alerts, or fraud prevention measures.

[0618] Examples of criteria that may trigger a transactional flag include:

[0619] (a) Unusually large transfer amounts

[0620] (b)Transactions occurring outside typical time windows

[0621] (c) Transfers to new or unverified beneficiaries

[0622] (d) Activity from unexpected geographic locations or IP addresses

[0623] (e) Sudden changes in transaction frequency or behaviour patterns

[0624] In the context of duress or security systems, a transactional flag might be used to silently trigger a duress mode if, for instance, a user tries to transfer an unusually high amount under suspicious circumstances.

Claims

PATENT CLAIMS1. A security arrangement for a financial transactional platform including a 3rd step in authentication for an online electronic fund transferring platform or in app authentication for transactions on mobile devices or web-based platforms, and adapted to be utilised by a client and / or user, which includes at least one of the following means to activate and / or trigger duress mode(a) during the login process;(b) while logged in to the FTP under normal conditions;(c) on a third-party mobile phone / device; and / or(d) duress mode can be triggered on the client' s / user's device while transacting at an ATM, POS or payment gateway.

2. An arrangement as claimed in claim 1, in which upon Logging in to the banking app, website, or online platform; by the bank's required means, such as biometric login on a mobile device or using an in app authentication, One Time Pin protocol or QR code for a web based or desktop application access, the banking client / user would then also be required to enter a PIP (Personal Identification Protocol) on their phone / mobile device (e.g. via a push notification in their banking app, or directly in the banking app), this could be in the form of a PIN, Password,Pass Phrase, alternate Biometrics, physical security key or second user / person / device or any other means of authentication, to access their online banking application or website; by entering a correct PIP, normal banking profile access will be granted, however should an incorrect PIP be used, or a duress pin, reversed pin, predetermined duress PIP, or any other predetermined method of indicating duress (e.g. Outside predetermined geofence, outside predetermined transactional times, etc), the banking app / website will still be opened, but in a "Duress Mode", the phone or mobile device used to trigger the duress mode may trigger various duress profiles as determined by the bank and / or client.

3. An arrangement as claimed in claim 1; in which while logged in to the banking app or website normally and not under duress, certain parameters may be set to trigger a duress mode as an additional safety feature for the client, this will also trigger the silent duress profile.

4. An arrangement as claimed in claim 1, in which while transacting at an ATM or POS, parameters are set to trigger a duress mode, e.g. large transaction amount, geolocation, multiple withdrawals and similar.

5. An arrangement as claimed in claim 1, in which a family member's or business partner's (Third Party) mobile device could be triggered into duress mode.

6. An arrangement as claimed in any one of the preceding claims, in which the Duress mode will trigger a security protocol and / or a duress profile based on the type of activation.

7. An arrangement as claimed in any one of the preceding claims, in which Duress mode is triggered at the login stage, but the Banking Profile will be the full profile of the Client; however, the bank will then be aware that the client / user and profile is under duress and the Profile will have no changes to it and will be fully functional.

8. An arrangement as claimed in claim 7, in which a Simpler / Alternate profile will open and appear to be the person's normal bank account, namely an "under duress" profile, and any additional profiles and / or accounts the client / user has, may or may not be visible / accessible and may or may not have decreased functionality or visible funds and / or reduced accessible amounts; and / or this the profile has accounts with a reduced balance visible and "available"; and / or any access bond accounts, Investment accounts, offshore accounts, share / trade accounts may or may not be visible and if visible may or may not have a reduced amount; and / or these amounts can be determined by the bank and could be generated randomly if need be or possibly be determined by the bank's client; and / or the rest of the banking app / website will have full and normal functionalityi.e. being able to add beneficiaries, increase daily limits for transferring funds, perform instant EFT's. In other words, it should "look and feel" exactly like the normal online banking facility.

9. An arrangement as claimed in any one of the preceding claims, in which a Security Protocol is activated when the "Under duress profile" or "Unchanged Under Duress Profile" is activated.

10. An arrangement as claimed in claim 9, which includes at least one of the following protocols:(a) If a website or desktop application on a PC, Desktop, laptop, notebook, tablet, or other device is used, the client's / user's mobile device will be triggered to activate duress mode on their mobile device application;(b)The bank's security / fraud division is immediately made aware that a duress profile has been activated;(c) The IP address of the PC, desktop, tablet or any other device is logged and sent to the bank.

11. An arrangement as claimed in any one of the preceding claims, in which at least one of the following is triggered on the client's mobile device / phone:(a) A GPS location is sent to the bank, and / or security company / kidnap and Ransom Task Force;(b)This GPS location is a "live view" and "always on";(c) The GPS location is available to the bank or security company / kidnap and Ransom Task Force even if the app / website is closed down or logged out of;(d) Cell tower triangulation or any other means of determining the device's location is activated;(e) a message / notification of the incident is sent to the client's nominated contact or contact list.

12. An arrangement as claimed in claim 11, in which the GPS location is available, even if the mobile device / phone is turned off (If possible / available on the device, as in the case with iPhone), in order to allow the mobilization of an Armed Response / Kidnap / Ransom negotiating team and give them the exact location and opportunity to rescue the victim if they are held against their will; and if the GPS location is disabled in the mobile device or phone's settings, then the banking app will not be able to log in, nor should it be allowed to authenticate a log in on a website or other device or platform.

13. An arrangement as claimed in any one of the preceding claims, in which the Device's camera and microphone may also be activated to monitor the surrounding environment and recorded remotely; this could be on the mobile device as well as laptop / PC.14.An arrangement as claimed in any one of the preceding claims, which includes at least one of the following features:(a) The funds that are transferred out of the account may appear to have left the account and appear to be deposited into the receiving bank used by the criminal account, there could be a delayed, reversable, or fake transaction;(b)The receiving bank used by the criminal should be informed that these funds are stolen and upon receipt of the stolen funds or notification thereof, the receiving bank used by the criminal could send a fake transaction confirmation message;(c) These funds are flagged as "under duress funds" and may be a "fake" entry into the receiver's account so that it appears as if the funds have been transferred;(d) The transactions are blocked by collaboration with the receiving bank used by the criminal; and / or(e) These funds appearing in the receiver's account may require a clearance time before the funds are available and thus allow the bank to reverse these transactions or deal with them in any manner they deem fit, an example would be to require the account holder of the stolen funds to come into the bank and then dealt with accordingly.

15. An arrangement as claimed in any one of the preceding claims, which includes a Silent Duress Profile activated in the following manner:(a) if a client / user is afraid of activating the duress mode, certain transaction parameters (such as if a pin is required for a large transfer amount or for when a beneficiary is added; then a duress pin, reverse pin or wrong pin etc) or "transactional flags" should trigger a "silent duress profile.";(b)The "Silent Duress Profile" will be the client's normal profile with full functionality;(c) The bank will be notified that the "silent duress profile" has been activated;(d)The funds that are transferred out of the account appear to have left the account and be deposited into the criminal's account, there could be a delayed, reversable, or fake transaction;(e) The criminal's bank is informed that these funds are stolen;(f) Upon notification or receipt of the stolen funds the receiving bank used by the criminal could send a fake "transaction confirmation message";(g) These funds are flagged as "under duress funds" and may be a "fake" entry into the criminal's account so that it appears as if the funds have been transferred;(h)These funds appearing in the criminal's account may require a clearance time before the funds are available and thus allow the bank to reverse these transactions or deal with them in any manner they deem fit, an example would be to require the account holder of the stolen funds to come into the bank and then dealt with accordingly.

16. An arrangement as claimed in any one of the preceding claims, in which a Silent Duress Profile is activated in at least one of the following manners: Transactional Flags selected from the group consisting of: PIN Code Variation, Biometric Duress Signal, Voice Command, Silent Button Activation, Long Press or Gesture, Accelerometer or Device Movement, Geolocation Triggers, Facial Recognition Duress Signal, Wearable Device Integration, Time-Based Activation, loT / Connected Device Signal, Double Authentication Attempt, Delayed Authentication, Preconfigured Companion Signal, Camera-Based Signals, Application Interface Triggers, Proximity Sensor Activation, Headphone Jack or Accessory Input, Bluetooth Device Signal, Custom Tap Sequences, Battery Status Trigger, Screen Pattern Variations, Environmental Noise Detection, Silent Signal from Another Device, NFC Tag or Card, Custom Swipe Gestures, Multiple Device Sync, Power Button Code, Device Removal or Disconnection, Simulated App Crash, Temperature Sensor Triggers, Gaze Detection,Heartbeat or Stress Level Monitoring, Haptic Feedback Signals, Al Behavioral Analysis, Incorrect Login Attempts, Constant Face Scanning; Abnormal transactions;. Preset transaction rules; Addition of Biometrics.

17. An arrangement as claimed in any one of the preceding claims, in which a Family Member / Partner Alternative Device Duress Mode is activated if a Family member / partner (or any other nominated person) is kidnapped and demands are made for the family to transfer funds, and in which there are one or both of the following scenarios:(a) If the family member / partner / associate etc. has the same banking app, the person that has been requested to perform the transfer of funds can tell the kidnappers that the person who is kidnapped is responsible for authentication of large transfers, this will activate the duress mode on the kidnapped persons phone, this will also cause the kidnappers to turn the phone on, should it have been turned off; this can be done in the following manner: Individual "Third Party Duress Contacts" should be preloaded on the client's profile; the bank is immediately notified that a Family member / partner is held under duress; this is done by various means such as calling the bank, activating within the banking site or app by a link or any other means determined by the bank; the kidnapped person's "Third Party Duress Contact" can be selected from within the client's profilethereby activating the "Family member / Partner Alternative Device Duress Mode"; a transaction authentication ("In app authentication" or "One Time Pin" etc, that has to match the sender's pin) or any other form of transaction authentication protocol is sent to the kidnapped persons phone, by entering / acknowledging the authentication protocol such as an in-app message or OTP, the kidnapped person's phone and banking app will enter duress mode; the transactions will appear to have gone through but would be flagged as under duress; an additional option would be that the first transaction authentication "fails" which still activates the duress security protocol, but does not initiate the "transfer of funds"; the kidnappers can be called a while later to be advised that the transaction failed and has to be authorized again; alternatively, the kidnappers can be told that the first authorization on the kidnapped persons phone is to transfer funds from a "holding / investment" account and once the funds are in the "current account" a second authorization is required to transfer the funds to the Kidnappers account; this will provide time for the security task force to be mobilized; the Duress Security Protocol will be activated on the kidnapped person's phone or mobile device and / or the device authorizing the fund transfer;(b) If the kidnapped person banks with a different bank and the family / partner / associate etc. is contacted to make a payment, there can be a kidnapping hotline that can be called for that specific bank; alternatively, Individual "Third Party Duress Contacts" should be preloaded on the client's profile, these "Third Party Duress Contacts" should include links that can cross communicate with other banks and their apps / websites via push notifications, in app authentication or even just an acknowledgment of an OTP, or any other means that allows the kidnapped person's bank to be notified; The kidnappers can be told that the kidnapped person is responsible for authenticating large transactions; a transaction authentication ("In app authentication" or "One Time Pin") or any other form of transaction authentication protocol is sent to the kidnapped persons phone, by their bank. By entering / acknowledging the authentication protocol such as an in-app message or OTP, or any other means, the phone and banking app will enter duress mode; this will activate the duress mode on the kidnapped persons phone, this will also cause the kidnappers to turn the phone on, should it have been turned off; these messages can be sent directly from the kidnapped persons bank as a standalone message to activate duress mode or may be used in conjunction with the person's bank that is making the transfer, therebyactivating the "Family member / Partner Alternative Device Duress Mode"; the transactions will appear to have gone through but would be flagged as under duress; an additional option would be that the first transaction authentication "fails" which still activates the duress security protocol, but does not initiate the "transfer of funds". The kidnappers can be called a while later to be advised that the transaction failed and has to be authorized again. Alternatively, the kidnappers can be told that the first authorization on the kidnapped persons phone is to transfer funds from a "holding / investment" account and once the funds are in the "current account" a second authorization is required to transfer the funds to the Kidnappers account; this will provide time for the security task force to be mobilized; the Duress Security Protocol will be activated on the kidnapped persons phone or mobile device and / or the device authorizing the fund transfer.

18. An arrangement as claimed in any one of the preceding claims, in which an in app or push notification PIP may be required as an additional authentication method for logging in to a person's account on an ATM. Should an incorrect PIP or duress pin be used, then the duress mode will be triggered on the person's mobile phone.

19. An arrangement as claimed in any one of the preceding claims, in which, should a person be forced to withdraw cash from an ATM or POS, an in app duress pin, or incorrect PIP for the transaction could trigger a duress mode on the mobile phone of the person withdrawing funds; the PIP may be required for every ATM or POS transaction or only when a person withdraws cash over a certain amount or consecutive withdrawals; should an incorrect PIP or duress pin be used, then the duress profile may be activated on the ATM or POS and duress mode will be triggered on the mobile phone; The Duress Security Protocol will be activated on the person's phone or mobile device.

20. An arrangement as claimed in any one of the preceding claims, in which, if the incorrect PIP, duress PIN, or any other method used to activate duress mode is entered by mistake, and the client / user realizes the error, they should be able to notify the bank (e.g. Telephonically) to begin restoring normal account functionality through reactivation authentication; The bank may verify the client's identity using a secure method such as a passcode, passphrase, or knowledge-based questions (KBQs); if the correct responses are provided, the account can be reactivated within a standard timeframe— typically 24 hours— or sooner / later based on the client's request or the bank's policy. Dependingon the bank's procedures, this may restore either limited or full access to the account and its features; in addition, the bank may offer an online or in-app option to reverse duress mode; this would require entry of a designated PIN, passphrase, PIP, or successful completion of KBQs or other authentication mechanisms determined by the bank.

21. An arrangement as claimed in claim 20, in which the live GPS location must still be available during this period in case the client / user has been forced to call the bank / cancel the duress mode; the bank can then ask them for a passcode, passphrase, or any other manner to determine if the client / user is still under duress or if an actual mistake was made; if the correct reactivation authentication(password / passphrase / predetermined answers to questions etc.) is given then the account may be reactivated in 24 hours, or any other time frame as requested by the client or as determined by the bank, this may enable immediate limited functionality and transactions or full functionality; the bank / security task force / team could also ascertain whether the client is still under duress based on the client' s / user's geolocation or account interaction.

22. An arrangement as claimed in claim 20, in which if they require full access to their account sooner, they can go to their nearest branch to report in person that everything is ok, should this be a requirement of the bank.

23. An arrangement as claimed in any one of the preceding claims, in which if a kidnapper is aware that the person they kidnapped has activated the Duress Mode on their Banking app or website, they may force the client / user to deactivate the Duress Mode, in a manner described above or any other way the bank may require; should the client / user be forced to cancel the Duress Mode with reactivation authentication, an alternative "panic" password / pin / PIP, giving incorrect answers to knowledge based questions, or simply an incorrect PIP can be given or used that doesn't match the registered reactivation authentication method, triggering the unchanged under duress profile, allowing full restoration of the electronic banking website or App, thereby creating the perception to the kidnappers that full functionality of the client's profile has been restored and the duress situation has been cancelled; the Duress Security Protocol will remain active on the person's phone or mobile device.24.An arrangement as claimed in any one of the preceding claims, in which the bank may elect to provide the client with insurance to cover loss of funds under duress, to provide armed response when the duress profile isactivated and also kidnap and ransom insurance including release and / or rescue negotiation and / or the bank may opt to outsource the insurance to a third party.

25. An arrangement as claimed in any one of the preceding claims, in which the bank may provide the services of such as task force for rescuing the person held under duress and / or the bank may opt to outsource such services.

26. A security method for a financial transactional platform includes a 3rd step in authentication for an online electronic fund transferring platform or in app authentication for transactions on mobile devices or web-based platforms, and adapted to be utilised by a client and / or user, which includes the step of activating and / or triggering duress mode by means of at least one of the following:(a) during the login process;(b) while logged in to the FTP under normal conditions;(c) on a third-party mobile phone / device; and / or(d) duress mode can be triggered on the client' s / user's device while transacting at an ATM, POS or payment gateway.

27. A security arrangement for a banking and / or financial app, which includes the following security functions:(a) the client / user of the banking app is required to enter a PIP to access their online banking platforms;(b) should an incorrect PIP be entered, the online banking app / website will still be opened, but with the following occurring: a. any additional profiles the person has will not be visible; and / or b. a Simple profile will open up and appear to be the persons normal bank account - this profile will be an "under duress" profile and will have a reduced accessible amount visible and "available".

28. An arrangement as claimed in claim 27, in which the reduced accessible amounts available include those of any access bonds and / or market accounts and / or savings accounts, or such accounts.

29. An arrangement as claimed in claim 28, in which these reduced accessible amounts may be determined by the bank and may be generated randomly if necessary or possibly be determined by the bank's customer.

30. An arrangement as claimed in any one of claims 27 to 29, in which the rest of the bank app / website may have full and normal functionality, namely being able to increase daily limits for transferring funds etc. and may "look and feel" exactly like the normal online banking facility and the criminals may be able to transfer funds to other bank accounts, with instant transfers as per transaction request.

31. An arrangement as claimed in any one of claims 27 to 31, in which if the incorrect PIP is entered and the "duress profile" is activated, the following steps may be activated:(a) The bank's security / fraud division may immediately be made aware that a duress profile has been activated;(b) A GPS location may be sent to the bank;(c) The GPS location may be a "live view";(d)The GPS location may still be available to the bank even if the app / website is closed down.

32. An arrangement as claimed in claim 31, which allows the mobilization of an armed response / kidnap negotiating team and give them the exact location and opportunity to rescue the victim if they are held against their will.

33. A security arrangement substantially as hereinbefore described with reference to the accompany drawing.34.A security method substantially as hereinbefore described with reference to the accompany drawing.

Images