System and method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures

Abstract

Embodiments of the present disclosure disclose system and method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures in real-time The system includes a plurality of local monitoring subsystems deployed at respective financial institutions and communicatively coupled with a central monitoring subsystem. Each local subsystem is configured to receive transaction data, retrieve a respective profile of a sender and a receiver involved in the transaction, determine whether a transaction is likely fraudulent using one or more machine learning models and, upon such determination, generate a primary tag identifier comprising attributes of the transaction, institutional reference identifiers, and a hop level. This primary tag identifier is associated with the suspicious funds and propagates across subsequent transactions through tag identifiers that reflect the full lineage of the fund's movement. Responsive measures, such as conditional usage restrictions, are enforced in tandem with tag propagation, thereby enabling real-time fraud containment, inter-institutional tracing, and conditional intervention, overcoming limitations of isolated, rule-based systems and reducing the risk of illicit fund withdrawal or obfuscation.

Description

[0001] SYSTEM AND METHOD FOR TRACING LIKELY FRAUDULENT ELECTRONIC FUND TRANSACTIONS AND ENFORCING RESPONSIVE MEASURES

[0002] EARLIEST PRIORITY DATE:

[0003] This Application claims priority from a Provisional patent application filed in India having Patent Application No. 202441097996, filed on December 11, 2024, and titled “A SYSTEM AND A METHOD FOR PREVENTING FRAUDULENT TRANS ACTIONS”

[0004] FIELD OF INVENTION

[0005] Embodiments of the present disclosure relate generally to system and method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures. More specifically, embodiments of the present disclosure relate to system and method for monitoring suspected fraudulent transactions, tagging associated funds, tracing propagation of such funds, and enforcing conditional usage restrictions including facilitating fund recovery.

[0006] BACKGROUND

[0007] Contemporary financial systems are increasingly characterized by rapid, seamless, and ubiquitous access to banking services. With the proliferation of real-time payment infrastructures, digital wallets, and instant interbank transfer protocols, users now expect near-instantaneous processing of financial transactions. The operational emphasis across banking institutions and fintech platforms has thus shifted decisively toward minimizing latency, maximizing throughput, and ensuring continuous availability of transactional services.

[0008] While this evolution has enhanced user convenience and financial interoperability, it has concomitantly engendered significant exposure to fraudulent exploitation. The very attributes that make these systems efficient such as speed, automation, and accessibility are routinely manipulated by malicious actors to orchestrate and execute sophisticated financial fraud schemes. Once a fraudulent transaction is initiated within such a high-velocity ecosystem, the window for intervention is often exceedingly narrow, leaving financial institutions with minimal opportunity to intercept or reverse the transaction before the illicit funds are withdrawn, dissipated, or layered through additional transfers.

[0009] In this context, it is important to delineate the categories of individuals affected by such fraud. Broadly, fraud incidents may implicate two principal classes of victims. The first comprises individuals or entities who are directly defrauded typically through deception, impersonation, social engineering, or coercion and who themselves initiate the transaction under false beliefs. These transactions may appear legitimate on the surface but are the result of premeditated manipulation. The second category encompasses those whose accounts are appropriated or recruited for use as conduits for illicit fund movement. These so-called “mule accounts” serve as critical intermediaries for laundering, layering, or redistributing fraudulently obtained funds. Notably, mule account holders may be entirely unaware of the illicit nature of the activity, or they may knowingly facilitate such schemes in exchange for compensation, often under the guise of legitimate opportunities. In either scenario, these accounts serve to obfuscate the origin and destination of the funds, impeding efforts at detection and recovery.

[0010] While various fraud detection mechanisms have been implemented across the financial sector, their efficacy remains constrained by several inherent limitations. Existing systems often driven by pre-configured rule sets or trained analytical models may indeed flag transactions as anomalous or suspicious based on historical patterns or predefined criteria. However, these systems typically function in isolation and are principally geared toward detection, not preemptive control. Once a transaction is flagged, there are limited mechanisms in place within conventional systems to dynamically intervene in the flow of associated funds.

[0011] Moreover, traditional fraud detection systems frequently fail to account for the broader transactional context. They are generally designed to evaluate each transaction in isolation, without tracing the full lineage of related financial events. For example, even when a transaction is identified as having a high probability of fraudulent origin, existing systems seldom track its progression beyond the immediate transfer. There is often no active tracing of subsequent transactions, no interbank collaboration to hold or scrutinize incoming suspicious funds, and no systemic capacity to follow the transactional trail as the funds are rapidly moved, subdivided, or withdrawn via merchant endpoints. Consequently, by the time a financial institution becomes fully aware of the fraudulent nature of the transaction, the funds have typically already exited the system or become irretrievably entangled in a web of derivative transactions.

[0012] This fragmentation of oversight combined with a lack of real-time transactional conditioning renders conventional systems reactive at best. While they may provide alerts or retrospective insights, they lack the transactional intermediation layer necessary to proactively manage suspicious funds before irreversible actions occur. The result is a gap between fraud identification and actual fraud containment.

[0013] Compounding the problem is the rigid, binary nature of current intervention mechanisms. Upon detecting a suspicious transaction, financial institutions are generally limited to a dichotomous decision: either allowing the transaction to proceed in full or blocking the transaction or the associated account entirely at the point of initiation. Such coarse-grained control does not support scenarios in which the transaction itself such as a fund transfer may be permitted for continuity or customer experience considerations, while subsequent operations involving those funds such as cash withdrawal, merchant payment, or outward remittance are selectively restricted or subjected to conditional controls. This lack of transactional granularity prevents institutions from implementing calibrated interventions that preserve legitimate transaction fulfillment while safeguarding against misuse in the event the transaction later proves to be fraudulent. As a result, institutions are either compelled to halt potentially benign activity, introducing friction and user dissatisfaction, or to risk exposure by allowing full access to funds that may have originated from illicit or high-risk sources.

[0014] Furthermore, traditional systems do not sufficiently support intra- institutional or inter-institutional coordination to trace, conditionally lock, or redirect the flow of suspected funds, thereby enabling fraudulent actors to capitalize on institutional silos and exploit temporal delays in interbank fraud detection.

[0015] Accordingly, there exists a pronounced need for an integrated framework that addresses the shortcomings of conventional fraud response methodologies and systems. BRIEF DESCRIPTION

[0016] In accordance with an embodiment of the present disclosure, a system for tracing likely fraudulent electronic fund transactions and enforcing responsive measures is provided. The system comprises a plurality of local monitoring subsystems, each deployed at a respective financial institution, each of the local monitoring subsystems comprising one or more first processors and a first memory comprising first computer-executable instructions that, when executed by the one or more processors, cause the local monitoring subsystem to receive first transaction data associated with a first electronic fund transaction; retrieve a respective profile of a sender and a receiver corresponding to the first electronic fund transaction; determine, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data and the respective profile; and based on the determination: generate a primary tag identifier comprising one or more attributes of the first transaction data, one or more reference identifiers corresponding to financial institutions involved in the first electronic fund transaction, and a hop level; associate the primary tag identifier with the electronic fund received through the first electronic fund transaction; enforce the responsive measures on the electronic fund associated with the primary tag identifier; and monitor movement of the electronic fund or a portion thereof through one or more subsequent electronic fund transactions. The system further comprises a central monitoring subsystem comprising one or more second processors and a second memory comprising second computer- executable instructions.

[0017] In accordance with another embodiment of the present disclosure, a method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures is provided. The method comprises receiving first transaction data associated with a first electronic fund transaction; retrieving a respective profile of a sender and a receiver corresponding to the first electronic fund transaction; determining, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data and the respective profile; and based on the determination: generating a primary tag identifier comprising one or more attributes of the first transaction data, one or more reference identifiers corresponding to financial institutions involved in the first electronic fund transaction, and a hop level; associating the primary tag identifier with the electronic fund received through the first electronic fund transaction; enforcing the responsive measures on the electronic fund associated with the primary tag identifier; and monitoring movement of the electronic fund or a portion thereof through one or more subsequent electronic fund transactions.

[0018] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will follow by reference to specific embodiments thereof, which are illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the disclosure and are therefore not to be considered limiting in scope. The disclosure will be described and explained with additional specificity and detail with the appended figures.

[0019] BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The disclosure will be described and explained with additional specificity and detail with the accompanying figures in which:

[0021] FIG. 1 illustrates a network environment for implementing example techniques of a system for tracing likely fraudulent electronic fund transactions and enforcing responsive measures, in accordance with an example implementation of the present subject matter;

[0022] FIG. 2 illustrates a schematic diagram of a local monitoring subsystem, in accordance with an example implementation of the present subject matter;

[0023] FIG. 3 illustrates a schematic diagram of a central monitoring subsystem, in accordance with an example implementation of the present subject matter;

[0024] FIG. 4 illustrates a block diagram of an example of tracing likely fraudulent electronic fund transactions, in accordance with an example implementation of the present subject matter.

[0025] FIG. 5 illustrates a method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures, in accordance with an example implementation of the present subject matter;

[0026] Further, those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.

[0027] DETAILED DESCRIPTION

[0028] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.

[0029] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a nonexclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or subsystems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, sub-systems, elements, structures, components, additional devices, additional subsystems, additional elements, additional structures or additional components. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but not necessarily do, all refer to the same embodiment.

[0030] The term “plurality,” as used herein, means two or more, i.e., it encompasses two, three, four, five, etc. For example, the expression “plurality of local monitoring subsystems” encompasses two local monitoring subsystems, three local monitoring subsystems and so on.

[0031] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.

[0032] In the following specification and the claims, reference will be made to a number of terms, which shall be defined to have the following meanings. The singular forms “a”, “an”, and “the” include plural references unless the context clearly dictates otherwise. FIG. 1 illustrates a network environment for implementing example techniques of a system for tracing likely fraudulent electronic fund transactions and enforcing responsive measures, in accordance with an example implementation of the present subject matter. It should be understood that, although specific systems are depicted as distinct blocks in the schematic diagrams, any of these systems may alternatively be combined or separated through hardware and / or software implementations. Referring to FIG. 1, system 100 comprises a plurality of financial institutions 104, 106, 108 (shown as example, in real implementation, the system 100 may include more financial institutions). As used herein, a financial institution may include, but is not limited to, entities such as commercial banks, credit unions, online banks, payment service providers, digital wallet providers, neobanks, money transfer agencies, savings and loan associations, and other entities authorized to hold, transmit, or manage electronic funds on behalf of customers. These institutions may offer services including account management, real-time payments, interbank transfers, fund withdrawals, merchant payments, and remittance operations. The financial institution may operate through physical branches, online platforms, or mobile applications, and may participate in domestic or cross-border financial networks. In certain embodiments, a financial institution may also encompass regulated financial technology (fintech) platforms that are integrated into the broader payment ecosystem. While not shown in detail, each financial institution may further comprise internal components such as payment processing servers, transaction authentication modules, or internal compliance systems that facilitate and execute financial or electronic fund transactions. Electronic fund transactions may be initiated by users through electronic devices such as smartphones, personal computers, point-of-sale terminals, or banking kiosks. These user devices are connected to the financial institutions via secure communication channels, which may include public or private networks, virtual private networks, or other institution-specific secure protocols. Once initiated, a transaction is processed by the sending financial institution and directed to the receiving financial institution. As shown in FIG. 1, transactions such as 110A and HOB represent electronic fund transactions between respective institutions. For example, a transaction 110A may be initiated from financial institution 104 to financial institution 106. Similarly, transaction HOB may represent a fund transfer from financial institution 106 to financial institution 108. Each financial institution 104, 106, 108 can send and receive electronic fund transactions in real time or near-real time through conventional payment infrastructures, such as domestic payment rails, international settlement systems, or peer-to-peer transfer platforms.

[0033] In some embodiments, each financial institution 104, 106, 108 participating in system 100 is onboarded to the central monitoring subsystem 110 via a mandatory registration process. During registration, the institution 104, 106, 108 transmits a structured data payload to the central monitoring subsystem 110 comprising technical, operational, and compliance-specific parameters required for fraud tracing and inter-institutional coordination. The registration data includes institution identifier metadata, including legal name, operating entity ID, and jurisdiction-specific licensing or regulatory numbers, financial network identifiers, such as SWIFT BIC codes, ISO 9362 branch codes, domestic routing numbers (e.g., ABA, IFSC), SEPA participant codes, or FPS identifiers, enabling precise identification in interbank transactions, supported transaction protocols, including enumerations of message formats and APIs (e.g., ISO 20022, NACHA, proprietary JSON / RESTful APIs) used for real-time payment, ACH, or card-based transactions, transaction channel flags, indicating whether the institution supports mobile banking, internet banking, card-present terminals, ATM withdrawals, P2P transfers, merchant QR payments, or cross-border remittances, authentication and device fingerprinting capabilities, including types of multi-factor authentication used (e.g., OTP, biometric, FIDO2), supported device telemetry data (e.g., device ID, IP address, user-agent string, SIM region, GPS coordinates), compliance and audit endpoints, such as designated reporting contacts, API endpoints for manual review override communication, and service-level agreement (SLA) settings for alert escalation; and security and integration artifacts, including public encryption keys used for tag identifier exchange, digital certificate fingerprints, webhook URLs for fraud event notifications, and authentication tokens for secure API calls. Furthermore, during the registration process, the financial institutions 104, 106, 108 may provide respective profiles of corresponding account holders in respective financial institutions to the central monitoring system.

[0034] Upon successful ingestion and validation of the particulars received through the registration process, the central monitoring subsystem may assign a globally unique reference identifier to the registering financial institution. This reference identifier is persistently associated with the financial institution and embedded within tag identifiers that may be generated by local monitoring subsystems 104, 106, 108 during fraud detection events. The reference identifier enables traceability across the transaction graph and facilitates encrypted routing of tag metadata and responsive measure notifications between institutions. The registration data is stored in a secure, access-controlled directory within the central monitoring subsystem to ensure authenticated and integrity- verified communication throughout the lifecycle of tagged electronic funds.

[0035] Each financial institution 104, 106, 108 includes a corresponding local monitoring subsystem 104A, 106A, 108A deployed therein to monitor transactions locally and to determine whether a given transaction is likely to be fraudulent. The deployment of each local monitoring subsystem 104A, 106A, 108A may be implemented in various configurations depending on the infrastructure of the respective financial institutions 104, 106, 108. In some embodiments, the local monitoring subsystem 104A, 106A, 108A may be implemented as a dedicated software module hosted on the financial institution’s internal server infrastructure, such as a transaction processing backend or fraud detection platform. In other embodiments, the local monitoring subsystem 104A, 106A, 108A may be deployed as a containerized microservice or virtual appliance operating within a private data center or a secure cloud environment under the financial institution’s control. The subsystem 104A, 106A, 108A may be integrated with existing transaction gateways, database systems, or fraud risk engines of the financial institution to receive transaction data in real time.

[0036] The local monitoring subsystems 104A, 106A, 108A (described in greater detail with reference to FIG. 3), are configured to receive transaction data associated with the electronic fund transactions processed by the respective financial institutions. Based on the transaction data and the corresponding profiles of the sender and the receiver of the electronic fund transaction, if it is determined that the electronic fund transaction is potentially fraudulent, the electronic fund associated with the electronic fund transaction is tagged and is monitored for any subsequent electronic fund transactions of the electronic fund or portion thereof. In this way, the systems and methods described herein may determine whether transaction activity is fraudulent based on the already collected transaction data without relying on extraneous methods of data information gathering.

[0037] In the event of subsequent electronic fund transactions of the electronic fund or the portion thereof that was tagged, the local monitoring subsystem 104A, 106A, 108A may send the tag information and the transaction data as mapped machine-readable information 112A, 112B, 112C to a central monitoring subsystem 110. The central monitoring subsystem 110 is communicatively coupled to the local monitoring subsystems 104A, 106A, 108A at the financial institutions 104, 106, and 108 via one or more data communication networks. These networks may include, but are not limited to, institutional intranets (for example, a proprietary banking network), local area networks (LANs), wireless local area networks (Wi-Fi), private leased lines, or secure virtual private network (VPN) tunnels established over public infrastructure such as the internet. The central monitoring subsystem 110 receives and stores this information for cross-institutional correlation, traceability, and enforcement coordination. The transmission may occur in near real-time, depending on the operational configuration of the financial institution. Additional details pertaining to the architecture and operation of the local monitoring subsystems and the central monitoring subsystem are provided in FIGS. 3 and 4, respectively.

[0038] In accordance with an embodiment of the present disclosure, a system for tracing likely fraudulent electronic fund transactions and enforcing responsive measures is provided. The system comprises a plurality of local monitoring subsystems, each deployed at a respective financial institution, each of the local monitoring subsystems comprising one or more first processors and a first memory comprising first computer-executable instructions that, when executed by the one or more processors, cause the local monitoring subsystem to receive first transaction data associated with a first electronic fund transaction; retrieve a respective profile of a sender and a receiver corresponding to the first electronic fund transaction; determine, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data and the respective profile; and based on the determination: generate a primary tag identifier comprising one or more attributes of the first transaction data, one or more reference identifiers corresponding to financial institutions involved in the first electronic fund transaction, and a hop level; associate the primary tag identifier with the electronic fund received through the first electronic fund transaction; enforce the responsive measures on the electronic fund associated with the primary tag identifier; and monitor movement of the electronic fund or a portion thereof through one or more subsequent electronic fund transactions. The system further comprises a central monitoring subsystem comprising one or more second processors and a second memory comprising second computer- executable instructions. FIG. 2 illustrates a schematic diagram of a local monitoring subsystem 200, in accordance with an example implementation of the present subject matter. It may be noted that the foregoing system is an exemplary system and may be implemented as computer executable instructions in any computing or processing environment, including in digital electronic circuitry or in computer hardware, firmware, device driver, or software. As such, the system is not limited to any specific hardware or software configuration. As shown therein, the local monitoring subsystem 200 may comprise a first processor(s) 202, a first memory(s) 204 coupled to and accessible by the first processor(s) 202, and a communication interface 206 coupled to the first memory(s) 204. The functions of various elements shown in the figs., including any functional blocks labelled as "processor(s)", may be provided through the use of dedicated hardware as well as hardware capable of executing instructions. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" would not be construed to refer exclusively to hardware capable of executing instructions, and may implicitly comprise, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA). Other hardware, standard and / or custom, may also be coupled to the first processor(s) 202. The local monitoring subsystem 200 may further include other components such as, but not limited to, VO interfaces, sensors, logic circuits etc. The local monitoring subsystem 200 may be the same as local monitoring subsystem 104A, 106A, 108A shown in FIG. 1.

[0039] The first memory(s) 204 may be a computer-readable medium, examples of which comprise volatile memory (e.g., RAM), and / or non-volatile memory (e.g., Erasable Programmable readonly memory, i.e.. EPROM, flash memory, etc.). The first memory (s) 204 may be an external memory, or internal memory, such as a flash drive, a compact disk drive, an external hard disk drive, or the like. The local monitoring subsystem 200 may further include a communication interface 206 that may allow the connection or coupling of the local monitoring subsystem 200 with one or more other devices, through a wired (e.g., Local Area Network, i.e., LAN) connection or through a wireless connection (e.g., Bluetooth®, WiFi), for example, for connecting to the central monitoring subsystem 110, shown in FIG. 1 or any other systems or devices of the financial institutions. The interface 206 may also enable intercommunication between different logical as well as hardware components of the local monitoring subsystem 200. Further, the local monitoring subsystem 200 may include module(s) 208. The module(s) 208 may include a receiving module 208A, a retrieving module 208B, a sending module 208C, a training module 208D. The system 200 may include other modules (s) (not shown) and may implement similar or extended functionalities of the local monitoring subsystem 200. In one example, the module(s) 208 may be implemented as a combination of hardware and firmware. In an example described herein, such combinations of hardware and firmware may be implemented in several different ways. For example, the firmware for module(s) 208 may be first processor 202 executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the module(s) 208 may include a processing resource (for example, implemented as either single processor or combination of multiple processors), to execute such instructions.

[0040] In the present examples, the non-transitory machine-readable storage medium may store instructions that, when executed by the processing resource, implement the functionalities of modules(s) 208. In such examples, the local monitoring subsystem 200 may include the machine- readable storage medium storing the instructions and the processing resource to execute the instructions. In other examples of the present subject matter, the machine-readable storage medium may be located at a different location but accessible to the local monitoring subsystem 200 and the first processor(s) 202.

[0041] The local monitoring subsystem 200 may further include a tracing engine 210. The tracing engine 210 may be implemented as a combination of hardware and programming, for example, programmable instructions to implement a variety of functionalities of the tracing engine 210. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the tracing engine 210 may be executable instructions. Such instructions may be stored on a non-transitory machine-readable storage medium which may be coupled either directly with the local monitoring subsystem 200 or indirectly (for example, through networked means). In an example, the tracing engine 210 may include a processing resource, for example, either a single processor or a combination of multiple processors, to execute such instructions. In the present examples, the non-transitory machine- readable storage medium may store instructions that, when executed by the processing resource, implement tracing engine 210. In other examples, the tracing engine 210 may be implemented as electronic circuitry. The tracing engine 210 may further include a determination module 210A, a tagging module 210B, a propagation module 210C and a responsive module 210D.

[0042] The local monitoring subsystem 200 may include other engine(s) (not shown) that may implement functionalities that supplement functions performed by the local monitoring subsystem 200 or the tracing engine 210. Further, the system 200 includes data 212. It may be noted that such examples of the various functions are only indicative. The present approaches may be applicable to other examples without deviating from the scope of the present subject matter. It will be appreciated that one or more alternative or additional algorithms may also be stored in the first memory 204 and executed by the first processor 202 to achieve similar or extended functionality, without deviating from the scope of the present subject matter. The data 212 may include databases configured to store data which may include profiles 212A of individuals possessing accounts in the financial institutions. The profiles 212A may include account details 212A-1 such as account numbers, account type (e.g., savings, checking, current), and account status, transaction(s) patterns 212A-2, for example, average transaction amounts, frequency, and typical counterparties, historical data 212A-3 such as past transaction patterns, biometric details 212A-4, social media data 212A-5 corresponding to account holders. The data 212 may include tag identifiers 212B, transaction data 212C, global reference identifier(s) 212D, and hop level 212E. Further, the data 212 may include other data (not shown) which may include data processed, generated, retrieved, stored as a result of functions implemented by the local monitoring subsystem 200.

[0043] FIG. 3 illustrates a schematic diagram of a central monitoring subsystem, in accordance with an example implementation of the present subject matter. It may be noted that the foregoing system is an exemplary system and may be implemented as computer executable instructions in any computing or processing environment, including in digital electronic circuitry or in computer hardware, firmware, device driver, or software. As such, the system is not limited to any specific hardware or software configuration. The central monitoring subsystem 300 may be hosted on a cloud-based server. The cloud-based server may represent a single computer server or a collection of computer servers. As shown therein, the central monitoring subsystem 300 may comprise a second processor(s) 302, a second memory(s) 304 coupled to and accessible by the second processor(s) 302, and a communication interface 306 coupled to the second memory(s) 304. The functions of various elements shown in the figs., including any functional blocks labelled as "processor(s)", may be provided through the use of dedicated hardware as well as hardware capable of executing instructions. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" would not be construed to refer exclusively to hardware capable of executing instructions, and may implicitly comprise, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA). Other hardware, standard and / or custom, may also be coupled to the second processor(s) 302. The central monitoring subsystem 300 may further include other components such as, but not limited to, I / O interfaces, sensors, logic circuits etc. The central monitoring subsystem 300 may be the same as central monitoring subsystem 110 shown in FIG. 1.

[0044] The second memory(s) 304 may be a computer-readable medium, examples of which comprise volatile memory (e.g., RAM), and / or non-volatile memory (e.g., Erasable Programmable readonly memory, i.e.. EPROM, flash memory, etc.). The second memory(s) 304 may be an external memory, or internal memory, such as a flash drive, a compact disk drive, an external hard disk drive, or the like. The central monitoring subsystem 300 may further include a communication interface 306 that may allow the connection or coupling of the central monitoring subsystem 300 with one or more other devices, through a wired (e.g., Local Area Network, i.e., LAN) connection or through a wireless connection (e.g., Bluetooth®, WiFi), for example, for connecting to the local monitoring subsystem 104, 106, 108, shown in FIG. 1 or any other systems or devices of the financial institutions. The interface 306 may also enable intercommunication between different logical as well as hardware components of the central monitoring subsystem 300.

[0045] Further, the local monitoring subsystem 300 may include module(s) 308. The module(s) 308 may include a receiving module 308A, and a sending module 308B. The system 300 may include other modules (s) (not shown) and may implement similar or extended functionalities of the central monitoring subsystem 300. In one example, the module(s) 308 may be implemented as a combination of hardware and firmware. In an example described herein, such combinations of hardware and firmware may be implemented in several different ways. For example, the firmware for module(s) 308 may be second processor 302 executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the module(s) 308 may include a processing resource (for example, implemented as either single processor or combination of multiple processors), to execute such instructions.

[0046] In the present examples, the non-transitory machine-readable storage medium may store instructions that, when executed by the processing resource, implement the functionalities of modules(s) 308. In such examples, the central monitoring subsystem 300 may include the machine- readable storage medium storing the instructions and the processing resource to execute the instructions. In other examples of the present subject matter, the machine-readable storage medium may be located at a different location but accessible to the central monitoring subsystem 300 and the second processor(s) 302.

[0047] The central monitoring subsystem 300 may further include engine(s) 310. The engine(s) 310 may be implemented as a combination of hardware and programming, for example, programmable instructions to implement a variety of functionalities of the engine(s) 310. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the engine(s) 310 may be executable instructions. Such instructions may be stored on a non-transitory machine-readable storage medium which may be coupled either directly with the central monitoring subsystem 300 or indirectly (for example, through networked means). In an example, the engine(s) 310 may include a processing resource, for example, either a single processor or a combination of multiple processors, to execute such instructions. In the present examples, the non-transitory machine-readable storage medium may store instructions that, when executed by the processing resource, implement engine 310. In other examples, the engine(s) 310 may be implemented as electronic circuitry. The engine(s) 310 may include a rescission engine 310A.

[0048] The central monitoring subsystem 300 may include other engine(s) (not shown) that may implement functionalities that supplement functions performed by the central monitoring subsystem 300 or the rescission engine 310A. Further, the system 300 includes data 312. It may be noted that such examples of the various functions are only indicative. The present approaches may be applicable to other examples without deviating from the scope of the present subject matter. It will be appreciated that one or more alternative or additional algorithms may also be stored in the second memory 304 and executed by the second processor 302 to achieve similar or extended functionality, without deviating from the scope of the present subject matter. The data 312 may include databases configured to store data which may include tag identifier(s) 312A, and transaction details 312B. Further, the data 312 may include other data (not shown) which may include processed, generated, retrieved, and stored as a result of functions implemented by the central monitoring subsystem 300.

[0049] Referring to Figs. 2 and 3, the receiving module 208A corresponding to a local monitory subsystem 104 A and / or 106 A and / or 108 A is configured to upon initiation of first electronic fund transaction receive first transaction data associated with a first electronic fund transaction (it may be noted here that the terms like “first”, and “second” used herein do not indicate any order and are used to establish difference between similar items or elements). The first transaction data may include at least one of a transaction amount, a transaction timestamp, a currency type, a transaction type, a transaction status, a source account identifier, a destination account identifier, a source bank identifier, a destination bank identifier, a transaction channel, a device identifier, a browser or user agent string, a payment method, an internet protocol (IP) address, a geographic location, a SIM region or country code, a network identifier including a cell tower ID or Wi-Fi SSID (Service Set Identifier), a session identifier, and an authentication technique. These data elements may be obtained by the local monitoring subsystem 200 in real time or near real time from one or more internal components of the financial institution, such as payment processing servers, transaction gateways, digital banking interfaces, authentication systems, or mobile banking applications. For instance, the transaction amount, timestamp, and account identifiers may be captured directly from core banking transaction logs; the device identifier, browser string, and IP address may be collected from the client device used to initiate the transaction; geographic location, SIM region, and network identifiers may be retrieved from mobile network interfaces or app permissions; and the authentication technique may be derived from the method used for user verification during the transaction, such as biometrics, OTP, or password. These parameters together provide a multidimensional context for the transaction, enabling the machine learning model to assess fraud likelihood with higher precision.

[0050] Upon receipt of the first transaction data, the retrieving module 208B may be configured to retrieve a respective profile of a sender and a receiver corresponding to the first electronic fund transaction. Further, the determination module 210A may be configured to determine, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data 212C and the respective profile. The machine learning model may be iteratively trained and updated by a training module 208D using a combination of account details 212A-1, transaction(s) patterns 212A-2, historical data 212A-3, biometric details 212A-4, social media data 212A-5 corresponding to account holders and outcomes of manual review of electronic fund transactions determined to be fraudulent.

[0051] For example, transaction patterns 212A-2 may include the structure and flow of a transaction within a short or extended time window, such as an account transferring funds to multiple recipients in rapid succession (a smurfing pattern), or round-dollar transactions to previously unrelated accounts, which could indicate laundering. Further, user-specific historical transaction data 212A-3 may include the account holder’s prior transactional behaviour, such as average monthly spending, frequent payees, geolocations of routine transactions, and preferred transaction channels (e.g., ATM vs. mobile banking). For example, a transaction initiated from a foreign IP address with a high value and an unfamiliar beneficiary might be flagged as anomalous for a user with a strictly domestic transaction history. Likewise, biometric authentication metadata 212A-4 may include recent biometric verification signatures such as facial recognition results, fingerprint hash codes, or voiceprint features. A mismatch or deviation in biometric confidence levels e.g., a fingerprint scan failing multiple times before acceptance can act as a weak signal of possible account compromise. Similarly, social media data of the account holder 212A-5 may include public indicators of account takeover risk or sudden changes in financial behaviour inferred from social media profiles. For instance, the detection of posts indicating recent travel abroad may conflict with a transaction originating from the user’s usual location, or the presence of spoofed / fake social profiles linked to the account's contact data may signal fraud ring activity.

[0052] To process these, the system 200 may employ a combination of supervised learning algorithms such as logistic regression, decision trees, random forests, and support vector machines, which are trained on labelled datasets of known fraudulent and legitimate transactions. Unsupervised learning algorithms such as k-means clustering, isolation forests, or autoencoders may be used to identify outliers or detect emerging fraud patterns without needing labelled data. Predictive models such as time-series anomaly detectors or neural networks may anticipate future fraudulent behaviour based on trends and behavioural drifts. Furthermore, ensemble learning techniques such as AdaBoost, XGBoost, or stacked generalization may be utilized to combine the strengths of multiple models, thereby improving classification accuracy and robustness. The choice of algorithm may be dynamically optimized based on transaction context, feature availability, and model confidence thresholds. This comprehensive approach ensures that the system 200 not only identifies known fraud scenarios but also adapts to evolving threats across diverse digital and behavioural contexts.

[0053] In some embodiments, any suitable technique, whether currently known or developed in the future, may be utilized by the determination module 210A to identify whether an electronic fund transaction is likely fraudulent. The present application is not limited to the specific machine learning approaches or data types described herein. For example, rule-based systems, statistical anomaly detection methods, hybrid analytics frameworks combining heuristic scoring and Al models, graph-based link analysis for identifying suspicious transaction networks, and manual review workflows may also be employed either independently or in conjunction with the described machine learning models. The architecture of the system is sufficiently flexible to incorporate evolving fraud detection paradigms and thereby remains adaptable to emerging threats and changing regulatory requirements.

[0054] Based on the determination if it is determined that the first electronic fund transaction is likely to be fraudulent, the tagging module 210B may be configured to generate a primary tag identifier 212B comprising one or more attributes of the first transaction data 212C, one or more reference identifiers 212D(global reference identifiers, assigned to the financial institutions (corresponding to both sender and receiver) involved in the first electronic fund transaction, during registration or onboarding) corresponding to financial institutions involved in the first electronic fund transaction, and a hop level 212E. The hop level may indicate the level of propagation of the electronic fund along a transmission path. Further, the tagging module 210B may be configured to associate the primary tag identifier 212B with the electronic fund received through the first electronic fund transaction. The hop level is zero in the primary tag identifier indicating a first instance of tagging the electronic fund based on a determination that the first electronic fund transaction is likely fraudulent. Upon tagging, the responsive module 210D may be configured to enforce the responsive measures on the electronic fund associated with the primary tag identifier 212B. The responsive measures may include one or more conditional usage restrictions, wherein the one or more conditional usage restrictions allow transfer of the tagged electronic fund while concomitantly preventing withdrawal, payment, or purchase using the tagged electronic fund. Certain transfers may be further restricted based on geographical rules; for example, the tagged electronic fund may be prevented from being transferred to specific restricted countries, while still allowing domestic transfers within permitted jurisdictions. It may be noted that the electronic funds in an account that are not associated with any tag identifier remain unrestricted. The conditional usage restrictions may be enforced at the level of the account, transaction endpoint, or application interface. In some examples, the restrictions may be dynamic and may vary based on the type of transaction or the assessed risk level. Further, electronic funds in an account that are not associated with any tag identifier may remain unrestricted, ensuring that legitimate funds are not hindered by the enforcement mechanisms and that normal financial operations can continue without unnecessary disruption.

[0055] It may be noted here that tag identifiers may be generated structured, fixed-length or variablelength alphanumeric strings formed by concatenating multiple segments, each formed from specific attributes of the corresponding transaction data. These attributes may include, but are not limited to, reference identifiers assigned to the originating and receiving financial institutions, transaction channel codes, currency codes, geographic or jurisdictional codes, and hop level indicators, timestamps, device or terminal identifiers, sequence counters, unique random or cryptographic values. For instance, a tag identifier such as B01B02W2INR00 may include B01 for the originating bank’s reference identifier, B02 for the destination bank’s reference identifier, W2 denoting a web-based transaction channel, INR indicating the currency, and 00 representing the initial hop level. As the electronic fund propagates across multiple financial institutions or intermediaries, the tagging module may update the tag identifier dynamically by appending or modifying segments to include new reference identifiers and by incrementing the hop level (e.g., B01B02W2INR00 B01B02W2INR00_B02B03ATMINR01). This position-aware and semantically meaningful concatenation ensures that the tag identifier remains compact, traceable, and parseable by downstream monitoring subsystems, amongst other systems. The use of alphanumeric encoding enables representation of a wider range of transaction attributes, including those that contain alphabetic codes (e.g., currency or channel types), and facilitates interoperability across diverse financial and technical systems.

[0056] In certain embodiments, the tag generation logic may employ a deterministic concatenation scheme, in which specific data fields are concatenated in a pre-defined and immutable order according to a prescribed rule or schema. Each field may represent a fixed attribute of the transaction, ensuring that the tag follows a consistent structural pattern across systems while incorporating differentiating elements such as timestamps, counters, or unique suffixes to preserve uniqueness. For instance, the rule may define that the tag shall always follow the following sequence:

[0057] <OriginatingBankID><DestinationBankID><TransactionChannel><CurrencyCode><HopLevel ><UniqueElement>.

[0058] Under this rule, a transaction originating from bank B01 and received by bank B02 through a web channel (W2), denominated in INR, at hop level 00, and generated at a specific time instance Tl, may produce the tag B01B02W2INR00T1. Another transaction with the same attributes but initiated milliseconds later at T2 may yield B01B02W2INR00T2, thereby maintaining structural consistency while ensuring unique identification.

[0059] In some embodiments, the deterministic schema may include optional padding or delimiter elements to maintain fixed-length formatting. For instance, where the originating and destination bank identifiers are standardized to three characters and the hop level is expressed as two digits, the tag B01B02W2INR00T1 may occupy a consistent length. In another example, a cross-border transaction between banks USX and INR routed through a SWIFT channel may produce USXINRSWFUSD00A1, maintaining both deterministic structure and transaction-specific uniqueness. The deterministic approach thus ensures that tag formation is schema-driven, reproducible, and consistently parseable, while still embedding sufficient variability to distinguish between concurrent transactions.

[0060] In further embodiments, time- and sequence-based encoding may be utilized to embed temporal uniqueness within the tag. A timestamp with millisecond or microsecond granularity may be included, for example B01B02ATMINR250510101523124, distinguishing simultaneous transactions. Alternatively, a local sequence counter may be incremented for each transaction within a given session or terminal, yielding tags such as B01B02ATMINR001, B01B02ATMINR002, etc. In other embodiments, a device or terminal identifier may be embedded, e.g., B01B02ATM1234INR00, ensuring that even identical transactions at different terminals remain distinct.

[0061] In some embodiments, the selection of the tag generation method for all banks may be preconfigured and fixed by a system administrator or a regulatory operator via a secured configuration interface. Once configured, the selected method whether deterministic, timestampbased, sequence-based, device-based applies consistently across all participating financial institutions. This pre-configuration ensures uniformity in tag generation across the network, compliance with institutional or jurisdictional policies, and predictable interoperability, while eliminating the need for per-transaction automatic selection and that each transaction is assigned a globally unique and verifiable tag identifier. The resulting identifiers remain both machine- parseable and semantically meaningful, thereby enabling secure traceability, integrity verification, and interoperability across distributed financial networks, even under high concurrency and variable transaction loads.

[0062] Further, the propagation tracking module 210C may be configured to monitor movement of the electronic fund or the portion (that is tagged) thereof through one or more subsequent electronic fund transactions.

[0063] Upon initiation of the one or more subsequent electronic fund transactions, for each subsequent electronic fund transaction, the sending module 208C may be configured to: encrypt the primary tag identifier and the subsequent transaction data, and send to the central monitoring subsystem 300, notification of the subsequent electronic fund transaction. The notification comprises encrypted primary tag identifier and the subsequent transaction data.

[0064] In some embodiments, encryption techniques may include symmetric encryption algorithms such as Advanced Encryption Standard (AES) with 256-bit keys for performance-efficient encryption of data-in-transit, and / or asymmetric encryption techniques such as RSA (Rivest-Shamir- Adleman) or Elliptic Curve Cryptography (ECC) for secure exchange of encryption keys between subsystems. Each local monitoring subsystem 200 and the central monitoring subsystem 300 may be provisioned with cryptographic key pairs during registration or onboarding with the central monitoring subsystem. The encrypted data ensures confidentiality and integrity, thereby protecting the tag identifier and sensitive transaction metadata from unauthorized access or tampering during transmission across potentially insecure or shared network infrastructures. Additionally, digital signatures or message authentication codes (MACs) may be used to verify the authenticity and origin of the encrypted notification, ensuring trust in inter-institution communication.

[0065] Like the first transaction data, the subsequent transaction data may include at least one of a transaction amount, a transaction timestamp, a currency type, a transaction type, a transaction status, a source account identifier, a destination account identifier, a source bank identifier, a destination bank identifier, a transaction channel, a device identifier, a browser or user agent string, a payment method, an internet protocol (IP) address, a geographic location, a SIM region or country code, a network identifier including a cell tower ID or Wi-Fi SSID, a session identifier, and an authentication technique. These data elements may be obtained by the local monitoring subsystem in real time or near real time from one or more internal components of the financial institution, such as payment processing servers, transaction gateways, digital banking interfaces, authentication systems, or mobile banking applications. For instance, the transaction amount, timestamp, and account identifiers may be captured directly from core banking transaction logs; the device identifier, browser string, and IP address may be collected from the client device used to initiate the transaction; geographic location, SIM region, and network identifiers may be retrieved from mobile network interfaces or app permissions; and the authentication technique may be derived from the method used for user verification during the transaction, such as biometrics, OTP, or password. These parameters together provide a multidimensional context for the transaction, enabling the machine learning model to assess fraud likelihood with higher precision.

[0066] The notification may be received by the receiving module 308A of the central monitoring subsystem 300. Upon receipt of the notification, the sending module 308B of the central monitoring subsystem 300 may be configured to transmit the encrypted primary tag identifier 212B and the subsequent transaction data 212C to a receiving local monitoring subsystem corresponding to a receiving financial institution. The receiving module 208A of the receiving local monitoring subsystem corresponding to a receiving financial institution may be configured to decrypt the primary tag identifier and the subsequent transaction data. Further, the tagging module 210B of the receiving local monitoring subsystem corresponding to the receiving financial institution may be configured to generate a secondary tag identifier comprising one or more attributes of the subsequent transaction data, one or more subsequent reference identifiers corresponding to subsequent financial institutions involved in the subsequent electronic fund transaction, and a subsequent hop level. The subsequent hop level is formed by incrementing by one a prior hop level associated with a prior electronic fund transaction which involved tagging a fund associated with that transaction, immediately preceding the subsequent electronic fund transaction along a same transaction path. In one aspect, the tagging module may construct an extended tag identifier which may include the primary tag identifier and all intermediate tag identifiers, each corresponding to intermediate electronic fund transactions from the first electronic fund transaction to the subsequent electronic fund transaction along the same transaction path, concatenated with the secondary tag identifier. Furthermore, the tagging module 210B of the receiving local monitoring subsystem corresponding to the receiving financial institution may be configured to associate the secondary tag identifier with the electronic fund or the portion thereof received through the subsequent electronic fund transaction, thereby enabling full traceability of the movement of the tagged electronic fund.

[0067] In another aspect, to optimize storage, communication, or processing efficiency, the extended tag identifier may include only the primary tag identifier concatenated with the secondary tag identifier, omitting the intermediate tag identifiers, thereby retaining traceability relative to the origin while reducing the data volume required to store or transmit the secondary tag identifier. The tagging module 21 OB may further be configured to associate the secondary tag identifier with the electronic fund, or the portion thereof, received through the subsequent electronic fund transaction, thereby enabling traceability of the movement of the tagged electronic fund.

[0068] In some examples, the construction of the extended tag identifier may be manually configured by an operator via a user interface of the central monitoring subsystem. The operator may select whether the extended tag identifier includes all intermediate tag identifiers in addition to the secondary tag identifier, or only the primary and secondary tag identifiers. Such manual configuration allows the operator to explicitly tradeoff between complete traceability of the transaction path and reduced data storage, communication, or processing requirements, rather than merely optimizing system performance.

[0069] Further, the responsive module 210D of the receiving local monitoring subsystem corresponding to the receiving financial institution may be configured to enforce the responsive measures on the electronic fund or the portion thereof associated with the extended tag identifier, thereby continuing to restrict the use of the tagged electronic fund or the portion thereof. For instance, the responsive module 210D may be configured to allow access to the tagged electronic fund via core banking channels such as account-to-account transfers initiated through secure bank interfaces or internal settlement systems, while concurrently preventing usage through consumer-facing channels such as automated teller machines (ATMs), point-of-sale (POS) terminals, web-based e- commerce platforms, or mobile wallet applications and restricting access based on geographic criteria, such that the tagged fund cannot be transferred to or from financial institutions located outside of predefined jurisdictions, regions, or countries. The responsive module 210D may evaluate metadata associated with each transaction request such as a transaction channel identifier, terminal type, or initiating device class to determine whether the transaction is being attempted through an allowed or disallowed channel. Upon identifying a restricted channel, the responsive module 210D may block execution of the transaction involving the tagged electronic fund while allowing other unrestricted funds in the same account to proceed through any channel without restriction. In some implementations, the responsive module 210D may also interface with the financial institution’s transaction authorization system to intercept and block disallowed actions before processing.

[0070] In some examples, the responsive module 210D may be configured to allow a predefined observation window, providing sufficient time for victims or financial fraud monitoring (FRM) teams across multiple financial institutions to detect irregularities and report the suspected fraud. It is recognized that victims often realize scams within minutes; hence, the system 100 facilitates prompt action. If fraud is reported or suspected within this observation window, the responsive module 210D enables a one-click fund reversal mechanism across all affected accounts, enabling immediate rollback or hold of the tagged electronic fund. In an example, the responsive module (210D) may be configured, upon receiving a report of suspected fraud, to generate and transmit a secure notification message to one or more financial institutions involved in the transaction, instructing them to place a hold on the associated funds in response to the reported fraudulent activity. Conversely, if no fraud is reported or suspected during the observation window, the system 100 may be configured to automatically trigger a controlled release mechanism. This mechanism initiates removal of the tag associated with the tagged electronic fund across all accounts it has passed through, for a specified amount or transaction path, thereby restoring unrestricted access to the fund and halting further enforcement of responsive measures.

[0071] In some other examples, the responsive module 210D may be configured to allow a predefined observation window, providing sufficient time for victims or financial fraud monitoring (FRM) teams across a plurality of financial institutions to detect irregularities and report suspected fraud. It is recognized that victims often realize scams within minutes; hence, the system 100, particularly, local monitoring subsystem 200 facilitates prompt action. In a first mode of operation, if suspected fraud is reported during the observation window, the local monitoring subsystem corresponding to the receiving financial institution continues tagging and enforcement of responsive measures while the case undergoes review by that financial institution. Upon approval of the fraud report by the financial institution received via bank-local monitoring subsystem interface, a first message from the local monitoring subsystem 200 deployed at that respective financial institution is transmitted to the central monitoring subsystem 300. The receiving module 308A may be configured to receive this message. In response, the reversal engine 310A may be configured to send a second message via the sending module 308B to the financial institutions’ payment processing servers of the financial institutions involved in the tagged electronic fund transaction via the corresponding local monitoring subsystems to initiate reverse of the electronic fund to the originating bank. The reversal engine 310 of the central monitoring subsystem 300 may be configured to execute a reverse propagation of the electronic fund or portion thereof, along the previously recorded transaction path, in reverse order. For instance, if a first financial institution (Bank A) transfers an amount of 100 units to a second financial institution (Bank B), and Bank B subsequently transfers 50 units to a third financial institution (Bank C) and the remaining 50 units to a fourth financial institution (Bank D), the reversal process ensures that Bank D first returns 50 units to Bank B, and Bank C returns 50 units to Bank B, thereby restoring the full 100 units at Bank B. Subsequently, Bank B returns the 100 units to Bank A, thus completing the fund reversal. This stepwise reversal mechanism ensures that each financial institution returns only the portion of the electronic fund it had received, thereby maintaining transactional integrity and preventing imbalance. The reversal is orchestrated by the reversal engine 310B using tag identifiers and associated transaction paths stored within the system and is triggered by sending corresponding rollback instructions to the financial institutions’ payment processing servers of the financial institutions involved in the tagged electronic fund transaction via the corresponding local monitoring subsystems along the transaction path.

[0072] Contemporaneously, the rescission engine 310A of the central monitoring subsystem 300 may be configured to send stop instructions to each local monitoring subsystem involved in tagging the associated electronic fund or portion thereof and transmit release notifications to local monitoring subsystems corresponding to the financial institutions that received the tagged electronic fund or portion thereof, the release notifications indicating lifting the responsive measures and stopping tagging the associated electronic fund or portion thereof. Further, the reversal may be carried out to return the tagged amount to the originating financial institution using the previously recorded transaction path.

[0073] Conversely, if no fraud is reported within the observation window or if a reported fraud is not approved by the financial institution, no message is transmitted to the central monitoring subsystem. In such cases, the tagging and enforcement of responsive measures continue across the transaction path to safeguard the electronic fund.

[0074] In a second mode of operation, the observation window may be manually extended through a user interface provided by the local monitoring subsystem 200, allowing authorized personnel, such as financial fraud monitoring (FRM) teams, to select a longer observation period when additional analysis time is required. The manual selection may be performed via a graphical or programmatic interface that permits specification of an extended time period or adjustment of system parameters associated with the observation window. Alternatively, or in addition, the system may be configured to automatically extend the observation window based on real-time analysis of transaction activity. Specifically, the local monitoring subsystems may monitor metrics including the speed and number of new secondary tags being generated for the associated electronic fund, as well as withdrawal, transfer, or purchase attempts involving the tagged funds. When these monitored metrics indicate ongoing or unusual activity, the system may dynamically extend the observation window to allow sufficient time for detection and reporting of potentially fraudulent activity prior to initiating any reversal or rescission actions.

[0075] In a third mode of operation, the system 100 may enable extended manual review beyond the observation window. In this mode, the local monitoring subsystem may be configured to generate one or more reports comprising electronic fund transactions determined to be likely fraudulent. Each report includes a mapping of tag identifiers to respective transaction data and a rationale for the determination. These reports are stored and made available for manual review by designated personnel of the corresponding financial institutions. If, upon review, it is determined that the transaction is not fraudulent, the financial institution may transmit a message indicating that a previously tagged electronic fund transaction is determined not to be fraudulent to the central monitoring subsystem. In response, the rescission engine 310D may be configured to initiate removal of all tag identifiers (un-tagging) associated with the electronic fund or portion thereof involved in the reviewed transaction and transmit release notifications to local monitoring subsystems corresponding to the financial institutions that received the tagged electronic fund or portion thereof, the release notifications indicating lifting the responsive measures and stopping tagging the associated electronic fund or portion thereof, thereby halting enforcement of responsive measures and restoring unrestricted access to the fund.

[0076] FIG. 4 illustrates a block diagram of an example of tracing likely fraudulent electronic fund transactions, in accordance with an example implementation of the present subject matter.

[0077] FIG. 4 illustrates an example transaction flow 400 that demonstrates the multi-hop propagation of an electronic fund across different financial institutions along distinct transaction paths, with evolving tag identifiers assigned at each hop. In the example, a transaction flow 400 represents the directional flow of electronic fund transactions across multiple financial institutions 402-416, each deployed with a respective local monitoring subsystem (not shown) for tracing likely fraudulent electronic fund transactions and enforcing responsive measures.

[0078] In this example, a structured tag identifier is generated at each financial institution when it receives tagged funds. Each tag comprises, but not limited to, three primary segments: (i) a reference identifier corresponding to the originating financial institution; (ii) a reference identifier corresponding to the receiving financial institution; and (iii) a hop-level indicator that signifies the current depth of propagation. Further, the tag may also encode selective attributes of the associated transaction data for enriched traceability and downstream analytics.

[0079] For example, financial institution 402 initiates an electronic fund transfer from Account Al to Account Bl at financial institution 404 along the first transaction path 400 A, via a mobile banking application. The transaction occurs at timestamp 2025-03-01T10: 15:00Z, has transaction type “peer-to-peer transfer,” is conducted in INR, and uses channel “mobile app.” This is the first hop (hop level 00), and the local monitoring subsystem at the financial institution 402 determines that the transaction satisfies tagging criteria (e.g., based on velocity, anomaly score, or risk flag determined by the machine learning model). It generates the primary tag (TAG 1): F402-F404-00- MOB, the tag as shown herein comprises the channel as the selected attribute of the transaction data.

[0080] Along the first transaction path 400A, when the tagged electronic fund or portion thereof is sent to the financial institution 404, the TAG 1 is sent to the local monitoring subsystem at the financial institution 404, the local monitoring subsystem at the financial institution 404 receives the TAG 1 and when a transaction of the electronic fund or portion thereof is made from the financial institution 404 to 408, TAG 2 is generated similarly like TAG 1, hop level now being incremented by 1 becomes 01, the extended tag now comes TAG 1+ TAG 2, this concatenated tag is sent to the financial institution 408. Similarly, when a transaction of the electronic fund or portion thereof is made from the financial institution 408 to 406, TAG 3 is generated similarly like TAG 1 and TAG 2, with hop level now incremented by 1 now becomes 02, and the extended tag now comes TAG 1+ TAG 2+TAG 2, this concatenated tag is sent to the financial institution 406.

[0081] Further, from the financial institution 402, an electronic fund transfer from Account Al to Account Bl at financial institution 412, via a mobile banking application. The transaction occurs at timestamp 2025-03-03T10:15:00Z, has transaction type “peer-to-peer transfer,” is conducted in INR, and uses channel “internet banking.” This is the first hop (hop level 00), and the local monitoring subsystem at the financial institution 402 determines that the transaction satisfies tagging criteria (e.g., based on velocity, anomaly score, or risk flag determined by the machine learning model). It generates the primary tag (TAG 2): F402-F412-00-INB, the tag as shown herein comprises the channel as the selected attribute of the transaction data. Along the second transaction path 410B, when the tagged electronic fund or portion thereof is sent from the financial institution 402 to the financial institution 412, the local monitoring subsystem at the financial institution 402 generates TAG 2, based on the transaction attributes and tagging criteria (e.g., anomaly detection, fraud probability). This is the first hop in the second path, and thus the hop level is 00, resulting in TAG 2 being structured as F402-F412-00-<attr>, where <attr> may represent a selected transaction characteristic such as channel type or risk score. TAG 2 is sent along with the transaction data to the financial institution 412.

[0082] When a transaction of the electronic fund or a portion thereof is subsequently made from the financial institution 412 to the financial institution 414, the local monitoring subsystem at the financial institution 412 receives TAG 2, a new tag TAG 3 is generated, this time reflecting a hop level incremented to 01, and the resulting concatenated tag becomes TAG 2 + TAG 3. This combined tag (F402-F412-00-<attrl> + F412-F414-01-<attr2>) is transmitted to financial institution 414 in real-time or near real-time as the fund gets transacted.

[0083] Continuing further, when a portion of the electronic fund is transferred from the financial institution 414 to the financial institution 410, the local monitoring subsystem at financial institution 414 receives TAG 2 + TAG 3 and generates TAG 4 with an incremented hop level of 02. The resulting tag is now TAG 2 + TAG 3 + TAG 4, representing a persistent trace from the origin through each intermediary node (F402-F412-00-<attrl>+ F412-F414-01-<attr2> + F414- F410-02-<attr3>). This new concatenated tag is attached to the transaction sent to financial institution 410.

[0084] Finally, when the tagged electronic fund or a portion thereof is transferred from the financial institution 410 to the financial institution 416, the local monitoring subsystem at financial institution 410 receives the prior tag chain and appends TAG 5, with the hop level incremented to 03. The resulting tag becomes TAG 2 + TAG 3 + TAG 4 + TAG 5, signifying full propagation along the second transaction path 400B and enabling downstream financial institutions to identify the complete transactional lineage or full fund trail and apply appropriate responsive or tagging measures.

[0085] Throughout transaction flow 400, each financial institution receiving tagged funds uses its local monitoring subsystem to generate and append a new tag segment, preserving the original source while reflecting the new destination and hop level. These deterministic, structured tags allow for compact representation and enable consistent parsing and audit trail maintenance across distributed nodes. In combination with stored transaction data such as amount, channel, timestamp, type, IP address, and device or session identifiers this tagging framework enables both automated and manual traceability of potentially fraudulent funds.

[0086] Tags may also be used by downstream systems to enforce responsive actions (e.g., channelspecific restrictions, delayed release, or rollback eligibility). For example, if the transaction originating at the financial institution 402 along the first transaction path 400A is later deemed legitimate after manual review, the central monitoring subsystem may issue a rescission command referencing all tags with root or primary tag (TAG 1): F402-F404-00-MOB, prompting each downstream financial institution to release funds and lift restrictions. Conversely, if fraud is confirmed, the same tag lineage can be used to initiate rollback in reverse hop order (e.g., 406 — 408 404 402) to return the tagged amount.

[0087] In accordance with another embodiment of the present disclosure, a method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures is provided. The method comprises receiving first transaction data associated with a first electronic fund transaction; retrieving an account holder profile of an account holder initiating the first electronic fund transaction; determining, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data and the account holder profile; and based on the determination: generating a primary tag identifier comprising one or more attributes of the first transaction data, one or more reference identifiers corresponding to financial institutions involved in the first electronic fund transaction, and a hop level; associating the primary tag identifier with the electronic fund received through the first electronic fund transaction; enforcing the responsive measures on the electronic fund associated with the primary tag identifier; and monitoring movement of the electronic fund or a portion thereof through one or more subsequent electronic fund transactions.

[0088] FIG. 5 illustrates a method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures, in accordance with an example implementation of the present subject matter. Although the method 500 may be implemented in a variety of devices, for ease of explanation, the description of method 500 is provided in reference to the above-described system 100, particularly, local monitoring subsystem 200. The order in which the method 500 are described is not intended to be construed as a limitation, and any number of the method blocks described may be combined in any order to implement the method 500, or an alternative method. It may be understood that blocks of the method 500 may be performed in the system 100, particularly, local monitoring subsystem 200. The blocks of the method 500 may be executed based on instructions stored in a non-transitory computer-readable medium, as will be readily understood. The non-transitory computer-readable medium may comprise, for example, digital memories, magnetic storage media, such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

[0089] At block 502, first transaction data associated with a first electronic fund transaction may be received.

[0090] At block 504, a respective profile of a sender and a receiver corresponding to the first electronic fund transaction may be retrieved.

[0091] At block 506, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data and the respective profile may be determined.

[0092] At block 508, based on the determination, a primary tag identifier may be generated, the primary tag comprises one or more attributes of the first transaction data, one or more reference identifiers corresponding to financial institutions involved in the first electronic fund transaction, and a hop level.

[0093] At block 510, the primary tag identifier may be associated with the electronic fund received through the first electronic fund transaction.

[0094] At block 512, the responsive measures on the electronic fund associated with the primary tag identifier may be enforced.

[0095] At block 514, movement of the electronic fund or a portion thereof through one or more subsequent electronic fund transactions may be monitored. Collectively, the present subject matter solves the series of technical challenges introduced by the evolution of real-time, low-latency financial systems by embedding a distributed, multi- institutional mechanism for real-time fraud detection, transaction-level fund tagging, conditional intermediation, and fund recovery. To counter the exploitation of speed and automation by fraudsters, each local monitoring subsystem at a participating financial institution is configured to analyze first transaction data at the time of transaction origination using a machine learning model trained to detect features indicative of fraud. Upon such detection, the subsystem does not merely flag the transaction but proactively generates a primary tag identifier that maps selected attributes of the transaction including institutional references and hop level metadata to the funds themselves, thereby establishing a traceable digital identity for suspected funds before they can be dissipated. This ensures immediate initiation of responsive measures, such as conditional restrictions on usage, to prevent irreversible misuse while allowing continuation of certain operations (e.g., transfers) to maintain operational continuity. Regarding the dual victim categories, the invention responds to both cases: when the originator is socially engineered into initiating a fraudulent transaction, the local monitoring subsystem may flag the anomaly based on behavioral deviations; when mule accounts are involved, any subsequent transfer of tagged funds into such accounts automatically triggers tagging with secondary tag identifiers, derived by incrementing the prior hop level and aggregating all previous identifiers along the transaction chain. This cumulative tagging system enables the funds’ journey to be forensically reconstructed and the associated risk context to be preserved across multiple transaction hops.

[0096] Where traditional systems fail by acting in isolation and focusing only on detection, this present subject matter integrates dynamic control capabilities directly into each transaction path, allowing each local subsystem not only to detect but to also enforce real-time responsive measures including selectively disabling withdrawals or merchant payments based on tag metadata. Further, to overcome the inability of conventional systems to track derivative fund movements, each transaction involving previously tagged funds is reported in real-time to a central monitoring subsystem, which acts as a coordination hub to forward tag and transaction data to the relevant receiving local monitoring subsystems. These receiving subsystems decrypt the tag, regenerate the updated hop-level tag, and continue enforcement, thereby establishing a continuity of control over suspect funds even as they traverse through multiple banks or accounts. This architecture breaks down institutional silos by enabling interbank synchronization of fraud detection and fund containment efforts, solving the problem of fragmented oversight. By replacing the binary allow- or-block model with granular usage restriction mechanisms, the system permits the transaction to proceed when appropriate but prevents misuse by restricting sensitive actions like cash-out or remittance, thereby balancing customer experience with fraud prevention. Finally, the architecture supports manual review and conditional reversal of responsive measures through a mechanism where financial institutions can submit determinations that previously tagged funds were erroneously flagged, triggering a system- wide propagation of tag release instructions. This ensures that the system is both adaptive and reversible, aligning fraud mitigation with real-world banking workflows while retaining a continuous, traceable control path for suspect funds.lt will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof.

[0097] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person skilled in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

[0098] The figures and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, the order of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts need to be necessarily performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples.

Claims

1. I CLAIM:

1. A system for tracing likely fraudulent electronic fund transactions and enforcing responsive measures, comprising: a plurality of local monitoring subsystems, each deployed at a respective financial institution, each of the local monitoring subsystems comprising: one or more first processors; and a first memory comprising first computer-executable instructions that, when executed by the one or more processors, cause the local monitoring subsystem to: receive first transaction data associated with a first electronic fund transaction; retrieve a respective profile of a sender and a receiver corresponding to the first electronic fund transaction; determine, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data and the respective profile; and based on the determination: generate a primary tag identifier comprising one or more attributes of the first transaction data, one or more reference identifiers corresponding to financial institutions involved in the first electronic fund transaction, and a hop level; associate the primary tag identifier with the electronic fund received through the first electronic fund transaction; enforce the responsive measures on the electronic fund associated with the primary tag identifier; and monitor movement of the electronic fund or a portion thereof through one or more subsequent electronic fund transactions; and a central monitoring subsystem comprising: one or more second processors; and a second memory comprising second computer- executable instructions.

2. The system as claimed in claim 1, wherein the first computer-executable instructions that, when executed by the one or more first processors, further cause the local monitoring subsystem to:upon initiation of the one or more subsequent electronic fund transactions, for each subsequent electronic fund transaction: send to the central monitoring subsystem, notification of the subsequent electronic fund transaction, wherein the notification comprises encrypted the primary tag identifier and the subsequent transaction data.

3. The system as claimed in claim 2, wherein the second computer-executable instructions that, when executed by the one or more second processors, further cause the central monitoring subsystem to: upon receipt of the notification, transmit, the encrypted primary tag identifier and the subsequent transaction data to a receiving local monitoring subsystem corresponding to a receiving financial institution.

4. The system as claimed in claim 1, wherein the first computer-executable instructions that, when executed by the one or more first processors, further cause the receiving local monitoring subsystem to: decrypt the primary tag identifier and the subsequent transaction data; generate a secondary tag identifier comprising one or more attributes of the subsequent transaction data, one or more subsequent reference identifiers corresponding to subsequent financial institutions involved in the subsequent electronic fund transaction, and a subsequent hop level, wherein the subsequent hop level is formed by incrementing by one a prior hop level associated with a prior electronic fund transaction immediately preceding the subsequent electronic fund transaction along a same transaction path; perform one of the following according to a preset configuration: generate an extended tag identifier concatenating the the primary tag identifier, the second tag identifier, and all intermediate tag identifiers, each corresponding to intermediate electronic fund transactions from the first electronic fund transaction to the subsequent electronic fund transaction along the same transaction path; and generate an extended tag identifier concatenating the primary tag identifier and the secondary tag identifier omitting all intermediate tag identifiers, each corresponding tointermediate electronic fund transactions from the first electronic fund transaction to the subsequent electronic fund transaction along the same transaction path; associate the extended tag identifier with the electronic fund or the portion thereof received through the subsequent electronic fund transaction; and enforce the responsive measures on the electronic fund or the portion thereof associated with the extended tag identifier.

5. The system as claimed in claim 1, wherein the hop level is zero in the primary tag identifier indicating a first instance of tagging the electronic fund based on a determination that the first electronic fund transaction is likely fraudulent.

6. The system as claimed in claim 1, wherein the responsive measures comprises one or more conditional usage restrictions, wherein the one or more conditional usage restrictions allow transfer of the tagged electronic fund concomitantly preventing withdrawal, payment, or purchase using the tagged electronic fund, and wherein electronic funds in an account that are not associated with any tag identifier remain unrestricted.

7. The system as claimed in claim 1, wherein the first transaction data and the subsequent transaction data comprises at least one of: a transaction amount, a transaction timestamp, a currency type, a transaction type, a transaction status, a source account identifier, a destination account identifier, a source bank identifier, a destination bank identifier, a transaction channel, a device identifier, a browser or user agent string, a payment method, an internet protocol (IP) address, a geographic location, a SIM region or country code, a network identifier including a cell tower ID or Wi-Fi SSID, a session identifier, and an authentication technique.

8. The system as claimed in claim 1, wherein the first computer-executable instructions that, when executed by the one or more first processors, further cause the local monitoring subsystem to: generate one or more reports comprising electronic fund transactions determined to be likely fraudulent, each report comprising mapping tag identifiers to respective transaction data and a rationale for identifying the electronic fund transactions as likely fraudulent; and store the one or more reports for manual review.

9. The system as claimed in claim 8, wherein the second computer-executable instructions that, when executed by the one or more second processors of the central monitoring subsystem, further cause the central monitoring subsystem to: receive, from a respective financial institution associated with a respective local monitoring subsystem of the plurality of local monitoring subsystems, a message indicating that a previously tagged electronic fund transaction is determined not to be fraudulent; in response to receiving the message, initiate removal of all tag identifiers associated with the electronic fund or portion thereof involved in the reviewed transaction; and transmit release notifications to local monitoring subsystems corresponding to the financial institutions that received the tagged electronic fund or portion thereof, the release notifications indicating lifting the responsive measures and stopping tagging the associated electronic fund or portion thereof.

10. A method for tracing likely fraudulent electronic fund transactions and enforcing responsive measures, comprising: receiving first transaction data associated with a first electronic fund transaction; retrieving a respective profile of a sender and a receiver corresponding to the first electronic fund transaction; determining, using a machine learning model, whether the first electronic fund transaction is likely fraudulent based on the first transaction data and the respective profile; and based on the determination: generating a primary tag identifier comprising one or more attributes of the first transaction data, one or more reference identifiers corresponding to financial institutions involved in the first electronic fund transaction, and a hop level; associating the primary tag identifier with the electronic fund received through the first electronic fund transaction; enforcing the responsive measures on the electronic fund associated with the primary tag identifier; and monitoring movement of the electronic fund or a portion thereof through one or more subsequent electronic fund transactions

Images