Systems and methods for real-time fraud detection and financial crime prevention in banks and financial networks using behavioral biometrics

Abstract

A computerized system generates a combined inter-institution fraud-relatedness risk score for an inspected transaction involving a first party of a first bank transferring funds to a second party of a second bank. The system receives from the first bank a first set of fraud-related signals based on information it holds about the first party and the transaction, and from the second bank a second set of fraud-related signals based on information it holds about the second party and the transaction. The system then generates the combined inter-institution fraud- relatedness risk score by analyzing both sets of fraud-related signals together. The resulting score is provided to at least one of the banks; and if it exceeds a pre-defined threshold value, pre-defined fraud mitigation operations are automatically triggered to address potential fraudulent activity.

Description

Systems and Methods for Real-Time Fraud Detection and Financial Crime Prevention in Banks and Financial Networks Using Behavioral BiometricsCross-Reference to Related Applications

[0001] This patent application claims priority and benefit from US 63 / 720,194, filed on November 14, 2024, which is hereby incorporated by reference in its entirety.Background

[0002] Millions of people around the world utilize electronic devices on a daily basis, such as smartphones, tablets, laptop computers, and desktop computers. Electronic devices are utilized in order to perform various activities, such as, browsing the Internet, sending and receiving electronic mail (email) messages, capturing photographs and videos, engaging in a video conference or a chat session, playing games, or the like.

[0003] Some online activities may be privileged, or may require authentication of the user in order to ensure that only an authorized user engages in the activity. For example, a user may be required to enter a username and a password in order to access an email account, or in order to access an online banking interface or website.Summary

[0004] Some embodiments provide systems and methods for real-time fraud detection and financial crime prevention in banks and financial networks using behavioral biometrics.

[0005] For example, a computerized method generates a combined inter-institution fraud-relatedness risk-score for an inspected transaction in which a first party of a first bank is transferring funds to a second party of a second bank; by performing: (a) receiving from the first bank a first set of fraud-related signals, that are generated based on information that the first bank has about the first party and about the inspected transaction; (b) receiving from the second bank a second set of fraud-related signals, that are generated based on information that the second bank has about the second party and about the inspected transaction; (c) generating the combined inter-institution fraud-relatedness risk-score, based on an analysis that takes into account both: (cl) the first set of fraud-related signals that were generated by the first bank based on information that the first bank has about the first party and about the inspected transaction, and (c2) the second set of fraud-related signals that were generated by the second bank based on information that the second bank has about the second party and about the inspected transaction; (d) providing the combined inter-institution fraud-relatedness risk-scoreto at least one of: the first bank, the second bank; and if the combined inter-institution fraud-relatedness risk-score is greater than a pre-defined threshold value, then: triggering one or more pre-defined fraud mitigation operations.

[0006] Some embodiments may provide other and / or additional benefits and / or advantages.Brief Description of the Drawings

[0007] Fig. 1 is a schematic block-diagram illustration of a system, in accordance with some demonstrative embodiments.Detailed Description of Some Demonstrative Embodiments

[0008] The Applicant has realized that it may be difficult to estimate the level of potential fraud that is associated with a banking transaction, especially when two non-related banks or financial institutions or entities are involved.

[0009] For example, realized the Applicant, Bank A may receive from user Adam a command, through the banking website or banking app of Bank A, instructing Bank A to transfer funds from the bank account of User Adam at Bank A, to the bank account of User Bob at Bank B.

[0010] Bank A may collect and monitor data, and may analyze such data to detect various signals that indicate to Bank A whether or not this transaction is or may be fraudulent or related to financial crime, and / or signals that would allow Bank A to calculate an estimated fraud score or fraud relatedness score or fraud likelihood score or financial crime likelihood score for this transaction from the point-of-view of Bank A and based only on the information that is available to Bank A.

[0011] For example, Bank A may calculate a fraud-relatedness score for this transaction, based on biometrics and behavioral patterns that it can detect from User Adam’s interactions, from the hardware device and software components that User Adam is utilizing, from the typing characteristics and input-units utilization of User Adam, from the characteristics of the communication channel that User Adam is utilizing (e.g., a direct connection, a connection over a Virtual Private Network (VPN), a connection via a remote access module, a connection via a proxy server), and / or other data-items that Bank A can collect and analyze to deduce fraud-related signals.

[0012] Similarly, Bank B may calculate a fraud-relatedness score for this transaction, based on biometrics and behavioral patterns that it can detect from User Bob’s interactions, from thehardware device and software components that User Bob is utilizing, from the typing characteristics and input-units utilization of User Bob, from the characteristics of the communication channel that User Bob is utilizing (e.g., a direct connection, a connection over a Virtual Private Network (VPN), a connection via a remote access module, a connection via a proxy server), and / or other data-items that Bank B can collect and analyze to deduce fraud-related signals or financial crime relatedness signals.

[0013] The Applicant has realized that each of the two banks sees only one half of the whole picture, and may not be aware, and may miss, fraud-related signals or financial crime relatedness or signals of possibly fraudulent activity that only the other bank has or can see or can detect.

[0014] In a first example, Bank A may collect biometric data, behavioral data, data that is learned or extracted from user gestures and input unit interactions, data from sensors of the electronic device that is used by user Adam, data about past transactions performed by user Adam, and other data that allow Bank A to estimate a fraud relatedness score for this transaction. However, Bank A is not aware, and does not have access to, other fraud relatedness signals or financial crime relatedness signals that only Bank B may have based on past transactions User Bob, or based on user gestures and behavioral indicators and biometric data that Bank B has with regard to User Bob. It is noted that in accordance with some embodiments, the fraud-relatedness score that Bank A is attempting to estimate or calculate or determine, is a fraud-relatedness score (or a financial crime relatedness score) Per Transaction, or for a particular transaction; rather than for a User or for a Client / Customer; and therefore, information about, and fraud-related signals (or financial crime relatedness signals) about, the other party to the transaction (User Bob) would be beneficial for Bank A to determine or estimate the correct fraud-relatedness score of the Transaction between its customer (User Adam) and another entity who is not a customer of Bank A (namely, User Bob who is a customer of Bank B). In other embodiments, the scores or signals are generated per transaction and / or per user; or per a transaction-and-user.

[0015] For example, Bank A may have the unique information that the inputuser interactions that User Adam performs do not match regular or established or reference behavioral patterns that were deduced by Bank A from previous usage session / s of User Adam. For example, in previous usage sessions, User Adam has entered information manually by typing character by character on a physical keyboard and without using copy-and-paste operations or keyboard shortcuts; whereas right now, in a transaction that is being investigated or analyzed, the user that alleges to be User Adam exhibits data entry with extensive usage ofkeyboard shortcuts and copy-and-paste operations, and uses a touch-screen device. Similarly, in previous usage sessions, User Adam has always used a laptop computer and a Chrome browser to access the banking website in order to perform transactions; whereas in the currently-inspected transaction, the person who alleges to be User Adam is accessing the banking website from an iPhone smartphone and through a Safari browser. The fact that User Adam has fully authenticated a few minutes ago to Bank A, is not helpful or sufficient, because Bank A is still aware of the abnormality in the typing patterns and in the different device and software that are used, which raise fraud signals (or financial crime relatedness signals) even if the person who alleges to be User Adam has authenticated by using a correct username and password.

[0016] In this example, the formula that Bank A utilizes for estimating a fraud relatedness score for this transaction, may yield a fraud-relatedness score of only 48% based on the information that is available to Bank A.

[0017] Similarly, Bank B is on the receiving side of the funds for this transaction, and it may have its own information and data about User Bob and about other transactions in the bank account of User Bob. For example, Bank B may have the exclusive information, that Bank A does not have, indicating that the bank account of User Bob in Bank B appears to behave like a “mule” bank account, or as a temporary pipeline bank account that siphons funds that are received and are rapidly transferred out to a third party or to another bank account. Bank B may also have the unique information, that User Bob is always accessing his bank account using a Virtual Private Network (VPN) or using a proxy server. These two data items or fraud signals (or financial crime relatedness signals), that only Bank B has and that Bank A does not have, may allow Bank B to allocate or to estimate a fraud relatedness score of 45% to this transaction.

[0018] In this example, each of the two banks has a threshold value of 51% in order to put a transaction on hold and to require additional authentication methods or additional fraud mitigation operations, such as, requiring the user to provide an additional authentication factor, requiring the user to contact by telephone the fraud department of the bank, requiring the user to answer security questions, or the like.

[0019] The Applicant has realized that if one of the two banks would have known about the fraud relatedness signals (or financial crime relatedness signals) that only the other bank has, then at least one of the two banks would have managed to take this additionally information and those additional fraud signals into account and to increase the fraud-relatedness score (orthe financial crime relatedness score) to beyond its own threshold value, to freeze or hold the transaction until further clarifications are received.

[0020] The Applicant has also realized that due to regulatory and legal constraints, banks may not be at liberty to transfer information about clients or about transactions to third parties, including to other banks, even if such sharing of information would be beneficial for improved detection of fraud or financial crime.

[0021] The Applicant has realized that it would be beneficial or advantageous to allow at least partial sharing or partial exchange of fraud-related data or signals or financial crime relatedness scores or signals, among Banks and / or from such Banks towards a trusted third-party solution provider, in a manner that still complies with bank confidentiality requirements and constraints; in order to enable an improved generation of a fraud relatedness score that takes into account data collected by two banks and not only by one bank.

[0022] For demonstrative purposes, some portions of the discussion above and / or herein may relate to fraud detection / prevention / mitigation; and some embodiments may be specifically configured to provide financial crime detection / prevention / mitigation, or to detection / prevention / mitigation of crimes or offenses or fraudulent activity in a banking network / financial network / payments network / credit card clearance network / electronic payment network.

[0023] In a first demonstrative embodiment, Bank A sends the transaction data to a trusted third-party device, with a fraud relatedness score that Bank A estimated based solely on the information that Bank A has. Similarly, Bank B, upon receiving a message that a transaction is incoming, sends to that same trusted third-party device its own fraud relatedness score that Bank B estimated based solely on the information that Bank B has. The trusted third-party device computes or determines a combined or unified fraud relatedness score (or financial crime relatedness score), which is then transmitted back to each of the two banks or to at least one of them; and each Bank can check whether the unified fraud relatedness score is above its threshold for freezing or canceling the suspicious transaction.

[0024] In a second demonstrative embodiment, each Bank sends to the trusted third-party device data indicating fraud-related signals that were collected by that bank. For example, Bank A may send to the trusted third-party device, a message indicating that an unusual pattern of keyboard usage was detected for the sending party, and that an unusual usage of hardware device and software browser where detected as well on the side of the sending party. Similarly, Bank B may send to the trusted-third party device, a message indicating that the receiving party has been interacting with his bank account via a proxy server or a VPN, and a messageindicating that transactions in the bank account of the receiving party appear to be similar to those exhibited by a “mule” bank account that is utilized as a pipeline for money laundering or terror funding or other illegal purposes. The trusted third-party device may aggregate or accumulate the fraud signals that it received separately from each of the two banks, and may generate a unified or combined or weighted fraud relatedness score or financial crime relatedness score, which is then transmitted to at least one of the two banks, which is then at a better position to determine whether or not to block or freeze this transaction.

[0025] In a third demonstrative embodiment, a trusted third-party device is not needed. Bank A can send directly to Bank B, together with the message indicating the data about the transaction itself, also an additional message that indicates which fraud-related signals were detected on the side of Bank A. Then, Bank B may take those signals into account, and may add them to a set of fraud-related signals the that Bank B has already gathered or determined by itself, thereby enabling Bank B to improve its own fraud-relatedness score or a financial crime relatedness score based on fraud-relatedness information or signals that it received from Bank B.

[0026] In a fourth demonstrative embodiment, again a trusted third-party device is not needed, and the roles this time are reversed. For example, Bank B can send directly to Bank A, in response to the incoming transaction data, a message indicating fraud-related signals or financial crime relatedness signals that Bank B has collected or determined, and that Bank A would now be able to take into account in estimating its own fraud-relatedness score.

[0027] In a fifth demonstrative embodiment, again a trusted third-party device is not needed, and this time the system performs both of the above-mentioned operations: Bank A sends to Bank B its own fraud-related signals, and Bank B sends to Bank A its own fraud-related signals, enabling each bank to re-calculate its own fraud-related score or financial crime relatedness score based on the additional signals that were provided by the other bank.

[0028] In accordance with another set of embodiments, a trusted third-party device may receive: (a) from Bank A, a hashed value that corresponds to a unique identifier of User Adam; and (b) from Bank B, a hashed value that corresponds to a unique identifier of User Bob; and (c) from each bank or from at least one bank, a unique Transaction Identifier number or a hashed value thereof. The trusted third-party device may include, or may have access to, a database storing hashed values of identifiers or entities (persons, corporations) that were known in the past to be involved in at least one fraudulent transaction. The trusted third-party device can perform a search in the database of hashed values of party identifiers, to check whether the hashed value of the identifier of the sending party (User Adam) appears as involved in a pasttransaction that was characterized as fraudulent; and / or to check whether the hashed value of the identifier of the receiving party (User Bob) appears in a past transaction that was characterized as fraudulent. If a match is found, then the trusted third-party device notifies at least one of the two banks that one or more of the two parties involved in this transaction have previously been a party to a fraudulent transaction, and the relevant bank(s) can take this into account as part of a re-calculation of their fraud-relatedness score or financial crime relatedness score.

[0029] In another demonstrative embodiment, at least one of the two banks may send, to the trusted third-party device and / or to the other bank, a message indicating additional information about that bank’s party, information that does not personally identify that party but that can be useful or helpful for assessing a combined or unified fraud-relatedness score. For example, Bank A may indicate to Bank B and / or to the trusted third-party device, that the transaction is being performed in a bank account that was opened five years ago and was used regularly for receiving salary paychecks (payroll checks) and for paying utility bills every month; whereas, Bank B may indicate to Bank A and / or to the trusted third-party device that the transaction is being performed towards a bank account that was opened only 3 hours ago. This combined information can help at least one of the two banks, and / or the trusted third-party device, to re-calculate a fraud relatedness score or a financial crime relatedness score that takes into account these two data-items. It is noted that the “account age period” or the “account usage patterns” described above are only non- limiting examples; and other data can be shared, particularly data that is inherently non-identifying its user, or data that was possibly identifying its user but was anonymized to discard identifying details.

[0030] In another demonstrative embodiment, at least one of the banks, or each bank, reports to the other bank and / or to the trusted third-party device, how many fraud-related incidents or how many suspicious yet cleared transactions were detected by that bank within the past N days (e.g., within the past 90 or 365 days, or since the account was opened); and such information may be used by the other bank and or / by the trusted third-party device to enable an improved generation of a combined fraud-relatedness score or a combined or crossbank / cross-institution financial crime relatedness score.

[0031] In another demonstrative embodiment, each bank also uses the same algorithm in order to generate a unique fingerprinting value or string, that identifies the specific hardware device and / or or software components that are utilized by the relevant party of that bank; and this information is transferred to the other bank and / or to the trusted third-party device, together with the transaction information, in order to check whether the same device is utilized on bothsides of the transaction, which by itself may be a fraud-related signal or a financial crime relatedness signal. For example, Bank A may create a particular value or hashed value that indicates which hardware components and / or software components are known to exist on the end-user device of the sending party, optionally indicating also which particular fonts are installed thereon; and similarly, Bank B may create a particular value or hashed value that indicates which hardware components and / or software components are known to exist on the end-user device of the receiving party, optionally indicating also which particular fonts are installed thereon. Bank A may send its Device-Identifying Value to Bank B or to the trusted third-party device; and / or, Bank B may send its Device-Identifying Value to Bank A and / or to the trusted third-party device; thereby enabling at least one of the banks, and / or the trusted third-party device, to detect that the same device is utilized on both sides of the transaction, thereby indicating by itself a possible fraud-related signal or a possible financial crime relatedness signal.

[0032] In another demonstrative embodiment, the trusted third-party device can share with each of the two banks, or with at least one of the two banks involved, information that it has about past fraud events or past potential fraud or past fraud-related incidents, that are known to the trusted third-party device based on the hashed identifier value of each party to the current transaction. For example, Bank A may indicate to the trusted third-party device, that the sender (User Adam) has been involved in 5 fraud related incidents in the past year; and the trusted third-party device may provide this information to Bank B, since Bank B has indicated to the trusted third-party device that Bank B is now performing a transaction in which money is incoming into Bank B from a payer that has a hashed identifier value that matches the hash identifier value for which the trusted third-party trusted device has fraud-related historical information.

[0033] In accordance with some embodiments, two banks (or two financial institutions or entities) can correlate a particular bank account or banking transaction to a particular user (or to a particular bank account), or can correlate a particular transaction to two particular users (or to two particular bank account), without necessarily sharing or exchanging, among themselves (among those two banks) and / or towards any third party, the full information that identifies the user / s of the respective bank accounts. For example, in some embodiments, Bank A need not share, with Bank B and / or with any trusted third-party, the information that User Adam’s bank account is “account number 1000273”, or that the user’s name is “Adam Jones”, or that the user’s date-of-birth is 05 / 05 / 1991, or similarly other personally identifiable information (PII) such as the user’s home address or social security number. Rather, forexample, Bank A may share, with Bank B and / or with a trusted third-party, only a Hashed Value of the bank account number of User Adam at Bank A; or, a Hashed Value of a string that includes both that bank account number and a unique identifier of Bank A (and / or of a particular branch of Bank A); or, a Hashed Value of the IBAN (international bank account number) of User Adam; or, a Hashed Value of a data-item indicating both the bank account number and the routing number; or, a Hashed Value of a data-item indicating both the bank account number and a SWIFT code (for routing purposes); or, another combination of the user’s first name and / or the user’s last name and / or the user’s account number and / or a unique identifier of Bank A and / or a unique identifier of the particular branch in which the account is managed and / or the bank routing number and / or the IBAN and / or the SWIFT code and / or other data-item that can enable another bank, or a trusted third-party, to correlate the hashed value that is outputted by Bank A, with a Hashed Value that another bank (or the trusted third-party) generates based on corresponding information. In some embodiments, optionally, the Hashed Value may further be based on a transaction date (e.g., in format yyyy-mm-dd), and / or on a transaction amount, and / or on a transaction serial number, and / or on other data-items that can assist the other bank (and / or the trusted third-party) to recognize which particular transaction is the subject of this fraud-relatedness inquiry; such as, to assist such entities to identify a particular transaction that User Adam performed on April 6th out of several transaction that User Adam performed on that date.

[0034] Some embodiments provide systems and processes for identifying unauthorized or irregular activities in the transfer of electronic funds between distinct financial entities. The embodiments rely on localized inspection of behavioral and transactional indicators, followed by secure exchange or aggregation of abstracted data through a neutral intermediary or controlled peer-to-peer channel. Within each entity’s infrastructure, computational components (such as signal extraction engines) analyze raw interaction logs and device telemetry, transforming them into vectorized feature sets for probabilistic risk scoring. Processing stages include ingestion of interface data, feature normalization, outlier identification, and generation of probabilistic assessments. The secure intermediary may operate as an encrypted cloud-based service using Transport Layer Security for transmission integrity and homomorphic encryption for partial evaluation of encrypted inputs. Peer-to-peer alternatives may employ mutual authentication certificates to ensure exclusive participation by approved nodes. Irreversible data transformations are applied using cryptographic hashing algorithms such as SHA-256, augmented by per-entity salts generated from time-based one-time passwords, to prevent reverse computation or correlation. Scalability and traceability are supported by distributedledger structures recording hashed metadata for audit verification without revealing sensitive contents. In certain embodiments, adaptive machine-learning models refine classification thresholds dynamically, adjusting to shifts in network activity and emerging fraud patterns within real-time transactional environments.

[0035] Conventional fraud-detection mechanisms in interbank transactions often exhibit partial visibility, especially when the sender and receiver belong to different institutions. A sending institution may detect anomalies in originator behavior, such as changes from sequential keystrokes on a physical input device to repetitive paste operations, or shifts in platform usage from fixed computers to mobile terminals. These variations can be quantified using edit-distance metrics for keystroke data or device fingerprinting via rendering analysis to expose inconsistencies. However, such a sender-side system lacks access to recipient- side irregularities, for example, repeated use of proxy relays or routing patterns consistent with transient holding accounts identified through graph analysis. The receiving institution, in turn, may observe those behaviors but remain unaware of the sender’s deviations, leading to isolated decision-making where correlated anomalies (such as identical IP mismatches or synchronized logins) go undetected. This separation of perspective causes underestimation of overall transactional risk and allows fraudulent transfers to propagate across financial networks. Legacy frameworks rely on static rule-based triggers without probabilistic fusion, missing opportunities to apply Bayesian inference models that could synthesize partial evidence. Data-sharing prohibitions further limit coordination, motivating development of abstraction layers that permit informed aggregation without disclosing sensitive details. The result of these deficiencies is persistent false negatives and diminished operational efficiency in fraudprevention workflows.

[0036] To mitigate such limitations, some implementations enable each financial entity to independently analyze its own participant interactions and device profiles, producing compact statistical representations that can be transmitted to a neutral coordinator or directly to a counterpart institution. This analysis employs sensor-fusion techniques combining diverse input sources, such as accelerometer and touch-screen data, to verify behavioral coherence. Time-series inputs are processed through recurrent neural networks for detection of deviations from baseline activity. Summarized feature sets are produced using dimensionality-reduction algorithms, for instance principal component analysis, to preserve discriminative features while minimizing bandwidth. Transmission occurs through authenticated APIs using tokens and nonce-based replay protection. The coordinator unit (e.g., implemented as an isolated virtual instance) integrates multiple submissions through ensemble weighting informed by priorcalibration data. Direct peer-exchange embodiments may apply zero-knowledge proofs to confirm computational integrity without revealing underlying features. Latency reduction is achieved through distributed or edge processing nodes performing early-stage filtering. The architecture thus permits modular adaptation, allowing financial entities to deploy specialized preprocessing routines aligned with regional compliance or institution- specific threat models.

[0037] In certain configurations, the originating financial institution collects and processes behavioral and environmental data associated with a transaction initiator. Such data may include pointer-motion paths, keystroke -rate distributions, and touch-surface interactions, combined with readings from orientation sensors, accelerometers, and magnetometers embedded in the user’s device. Pointer trajectories are interpolated for path smoothing, while key-press frequencies are analyzed in the frequency domain using Fourier transforms to detect abnormal rhythm changes. Touch-pressure maps are evaluated to distinguish genuine finger contact from simulated input. Sensor readings are merged using Kalman filters to suppress noise and detect unnatural device handling. Network attributes, software identifiers, font inventories, and geolocation estimates derived from connection metadata are also captured. Network addresses undergo reputation analysis, software identifiers are hashed to verify consistency, and font inventories contribute to entropy-based uniqueness scoring. These parameters form a behavioral baseline, against which current sessions are compared through cosine-similarity metrics. Deviations such as abrupt input-method changes (e.g., from deliberate manual entry to automated paste sequences) or shifts between stationary and mobile hardware increase risk indicators computed through threshold classifiers. Historical transfer patterns, including transaction frequency and magnitude, are modeled using hidden Markov chains to estimate state transitions. Routing analysis differentiates direct from proxied connections using hop-count or latency profiling. The resulting evaluation yields a localized risk score, often derived from a logistic regression output, quantifying probability of misconduct based solely on the sender’ s internal evidence.

[0038] The receiving institution performs a parallel evaluation focusing on the fund recipient. It inspects access vectors for signs of concealment, including proxy headers, tunneling identifiers, or VPN artifacts detected through cipher-suite fingerprinting. It examines account tenure, transaction-flow topology, and credential-change recency to identify patterns resembling temporary holding conduits. Graph-based models analyze inflow and outflow correlations to reveal high clustering indicative of mule networks, while time-decay weighting assigns greater influence to recent credential modifications. Session behavior (e.g., duration, navigation order, frequency of balance queries) is clustered using algorithms such as DBS CANto locate outliers. If account activity shows rapid turnover or redistribution of funds, alert thresholds are raised proportionally. Device inventories are examined for matches against known compromised signatures using Jaccard similarity analysis. Combined results yield a receiver-side probability measure of illegitimacy, generated through gradient-boosted ensembles ranking feature relevance for interpretability and predictive precision.

[0039] To integrate both perspectives, the institutions exchange condensed analytical markers or forward them to an impartial arbiter under secure protocols. Condensed markers are derived through aggregation functions such as mean pooling or histogram binning to minimize payload while retaining essential distributions. The arbiter unit (e.g., operating as a containerized service with access-controlled isolation) receives and queues submissions for asynchronous fusion. Peer-to-peer exchanges use encrypted envelopes secured by ephemeral key pairs ensuring forward secrecy. Identifiers including account codes or personal data are converted into irreversible digests incorporating entity-specific salts produced from hardware random number generators. For example, a digest formed from an account token, timestamp, and transaction amount enables correlation without direct exposure. Bloom-filter indexing supports probabilistic matching with minimal memory use. Supplemental statistics (e.g., such as maximum recent risk values or aggregate transfer volumes) may be included, with differential-privacy noise added to prevent reconstruction of personal attributes.

[0040] Upon receipt, the neutral coordinator or counterpart entity merges the concealed inputs to compute a composite cross-institutional risk metric. The computation weights each source according to calibration data and employs models emphasizing concordant anomalies, for instance, shared device fingerprints suggesting unified control. Attention-based neural networks may be utilized to correlate cross-feature dependencies, while temporal alignment modules verify simultaneous irregularities across systems. Relational embeddings or graph neural networks can propagate risk signals through connected transaction nodes, generating a network-level hazard index. When this index surpasses configured thresholds, automated responses activate, such as delaying execution, triggering secondary authentication, or notifying oversight channels. In arrangements without a third-party arbiter, institutions may directly exchange encrypted cues, updating internal risk estimates iteratively through feedback cycles until convergence criteria are satisfied.

[0041] This cooperative scheme avoids regulatory restrictions on raw data sharing by exchanging only anonymized derivatives, thereby enhancing fraud awareness while preserving confidentiality. Derived observations are generated using lossless compression or autoencoder models that maintain reconstructive accuracy during internal validation. Compliance withprivacy frameworks such as GDPR is achieved through data-minimization policies and selective attribute retention. Secure multi-party computation protocols permit crossverification of encoded attributes without exposing private content. The arbiter may query encrypted historical records of flagged entities to detect recurring associations through digest comparison, supported by index-based search on encrypted databases. In additional embodiments, anonymized non-identifying attributes (e.g., account age or typical activity cadence) are broadcast through publish-subscribe channels to maintain updated joint risk assessments in real time.

[0042] The core of the invention is this distributed yet cooperative evaluation model, wherein each financial entity conducts deep analysis within its jurisdiction while securely sharing summarized intelligence that, when combined, yields a comprehensive view of potential misconduct. Analytical routines may employ convolutional neural architectures for temporal pattern recognition, and variable-selection algorithms to emphasize high-impact indicators. Secure channels use monitored VPN tunnels equipped with intrusion-detection sensors to ensure integrity during transfer. The framework compensates for blind spots inherent in isolated surveillance and dynamically adapts through online learning techniques that update parameters as new threat behaviors emerge. A sender exhibiting irregular keystroke rhythms and a recipient displaying high turnover activity may individually generate minor alerts, yet when merged, these cues yield a definitive fraud indication, calibrated via receiver-operating-characteristic analysis to optimize sensitivity and specificity.

[0043] The described architecture scales across multiple organizations, including clearinghouses or payment processors, where complex routing requires extended data correlation. Scalability is achieved through containerized microservices permitting horizontal expansion. Clearing intermediaries may integrate with blockchain ledgers for immutable audit recording of risk metrics. High-volume aggregation is handled through distributed data-processing frameworks enabling parallel computation. Cryptographic rotation of encoding salts and restricted exposure policies ensure alignment with diverse jurisdictional privacy laws, with compliance verified via formal auditing tools. Learning models continuously retrain on depersonalized datasets using transfer-learning methods to detect evolving attack typologies such as emulated devices or coordinated laundering networks.

[0044] In operation, the system transforms isolated monitoring functions into an interconnected defense network. Individual anomaly detectors within each institution contribute to a shared federated architecture, exchanging learned parameters without transferring raw data. Privacy-preserving cryptographic primitives, such as thresholdsignatures, govern cross-entity updates and approvals. The result is an integrated financial environment in which transaction reliability increases, fraudulent activity declines, and data privacy remains intact. System resilience is maintained through redundant failover clusters and fault-tolerant orchestration. By separating localized analytics from collaborative synthesis, the invention maintains equilibrium between confidentiality and security, optimized through game-theoretic modeling balancing detection accuracy and privacy cost.

[0045] Extended embodiments employ secure multi-party computation at the arbiter to perform risk analysis over encrypted data inputs, eliminating the need for decryption. Boolean evaluations may be implemented via garbled circuits, and uncertainty handled through fuzzy-logic inference layers. In peer-to-peer variants, entities can verify signal authenticity through non-disclosure proofs such as succinct non-interactive arguments of knowledge (SNARKs). Container orchestration platforms manage dynamic deployment, supporting both bilateral and global clearing configurations. These features illustrate adaptability across domestic and cross-border financial infrastructures.

[0046] The present invention thus transitions fraud detection from institution-specific silos to a collaborative analytical ecosystem, merging localized intelligence into unified oversight without breaching confidentiality. Local feature extraction, protected transmission, and composite inference form an integrated methodology addressing the problem of inter-institutional opacity. Through this architecture, financial networks achieve more effective, privacy-conscious monitoring of transactional integrity on a global scale.

[0047] In a first demonstrative configuration, a trusted server operates as a clearinghouse that accepts one-sided outputs and one-sided fraud signals from the two participating financial institutions and computes a combined hybrid risk score for the inspected transaction. Each institution deploys an on-premise extraction engine that ingests local interaction logs, device signatures, channel metadata, and account-state descriptors, and that emits a compact representation consisting of a per-side risk score, feature summaries, and provenance tags. The compact representation is conveyed to the clearinghouse over a mutually authenticated API using a transport layer protected by TLS and session-level nonces to provide replay resistance. The data plane may employ streaming queues with idempotency keys so that retransmissions do not inflate counts. To maintain data minimization, the institutions send only hashed values for any field that could identify a person or an account. Hashing can be performed with a keyed construction, for example HMAC-SHA-256, with institution-specific salts that rotate periodically; salts can be derived from a hardware entropy source and escrowed under the institution’s key hierarchy. It is noted that in some embodiments, data-items may be“salted” digitally before being cryptographically hashed; whereas, in other implementations, such “salting” may be optional or may not be utilized, and data-items may be cryptographically hashed “un-salted” or without firstly being salted. The clearinghouse does not require raw fields and does not attempt to reverse the digests; it uses them solely to perform privacypreserving joins, such as determining that a sender-side device fingerprint and a receiver-side device fingerprint likely originate from the same physical transceiver or virtual environment. Where alignment across differing feature spaces is necessary, the clearinghouse applies a feature mapping layer that normalizes per-bank encodings into a common latent space. A fusion module then aggregates per-side scores with weighted evidence derived from cross-side concordances. The fusion can be implemented as a Bayesian combiner, a logistic stacker, or an attention-based correlator that emphasizes joint anomalies, such as co-temporal spikes in paste events on the payer side and immediate fan-out routing on the payee side. The clearinghouse also computes error bars and confidence intervals using calibration data supplied by each institution so that downstream decisioning can weigh the variance of the combined estimate. Optional secure multiparty computation permits evaluation of limited predicates over encrypted features when the parties elect to keep even hashed vectors opaque; in that case, the clearinghouse executes garbled circuits or homomorphic accumulators to produce the hybrid risk score without materializing plaintext. The clearinghouse returns to each bank a minimal response consisting of the combined risk score, a set of policy-neutral explanations or ranked indicators suitable for local audit, and a token that binds the computation to the transaction identifier for later dispute resolution. At the institutions, a decision module decides whether to allow, delay, or challenge the transfer. Because only hashed values and abstracted statistics were transmitted, the configuration satisfies data-sovereignty restrictions while still enabling cross-entity correlation. The clearinghouse can write a cryptographic receipt that includes only digests of inputs and outputs into an append-only audit log or distributed ledger so that regulators can later verify that the score was computed from the declared inputs without exposure of sensitive content.

[0048] In a second demonstrative configuration, the payer bank transmits its own per-side assessment directly to the payee bank, which uses the incoming indicators to update, refine, or override its local risk estimate for the same transaction and, if necessary, to block settlement on its side. The payer bank’s assessment includes a scalar risk score, a vector of stabilized features, and a compact set of event markers that describe conditions observed during initiation, such as rapid sequence pasting, sudden device substitution, geolocation inconsistency, or anomalous input cadence. The transmission may occur through a bilateralsecure channel established for interbank messaging, or through an overlay delivery network that provides routing, queuing, and rate limiting. To preserve privacy, any field that could identify a person, an account, or a device is converted into a hashed value before transmission, again using keyed hashing with rotating salts so that an adversary cannot reuse a digest across institutions. Where the payee bank needs to validate the authenticity of the payer’s signals, the payer bank can attach zero-knowledge proofs that a given digest corresponds to a value enrolled in the payer’s registry without disclosing the value. On receipt, the payee bank’s integration engine verifies message authenticity, checks idempotency, and consults its mapping table to align the payer’s features to the payee’s local schema. A posterior inference step then incorporates the payer-side score as informative prior evidence; for example, the payee can treat the payer’s scalar as a prior log-odds adjustment and then apply local likelihood terms derived from recipient-side telemetry, account age, velocity patterns, and graph-based indicators of fan-out or mule behavior. If the combined posterior exceeds a configured threshold, the payee bank may place the transaction in a pending state, demand step-up verification from the recipient, or decline the credit to the receiving account. Where the payer’s indicators contradict the payee’s own measurements, a reconciliation routine can trigger a secondary exchange for clarification with strictly limited additional fields and with continued use of hashed values for any persistent identifiers. The configuration supports partial availability; if the payer bank is temporarily unreachable, the payee bank proceeds with local scoring, and when the deferred message arrives it recomputes with the new prior. The message format can include a lifetime and a monotonic sequence number so that stale data is not applied out of order. The bilateral approach reduces latency relative to a centralized clearinghouse by eliminating a third hop and empowers the payee to act quickly with payer-side context. At all times, privacy is maintained because the payer conveys only digests and summarized indicators rather than raw logs, and the payee performs all decisioning within its own boundary.

[0049] In a third demonstrative configuration, the flow is inverted: the payee bank transmits its own per-side assessment to the payer bank, which incorporates the received signals into its local decisioning before authorizing the debit or before releasing funds to the settlement pathway. The payee bank has visibility into indicators that are typically unavailable upstream, including patterns of immediate redistribution, clustering of counterparties associated with prior chargebacks, sudden credential churn, atypical device inventories, and access through anonymizing gateways. The payee bank converts these observations into a quantified per-side risk score and a structured set of risk signals. Prior to transmission, the payee bank replaces all person-level and account-level fields with hashed values under arotating key regime and may incorporate additional privacy noise into aggregates if required by policy. It then sends the assessment to the payer bank through a mutually authenticated channel that uses ephemeral keys for forward secrecy and a message authentication code for integrity. At the payer bank, an intake service validates signatures, checks freshness, and associates the message with the pending transaction via a digest of the transaction token. A local combiner then integrates the payee-side score with the payer’s own behavioral analysis, which may include keystroke dynamics, device -use patterns, and channel risk descriptors. Several fusion strategies are usable. In one, the payer adjusts its own log-odds by an additive term derived from the payee’s scalar score. In another, the payer bank treats the payee’s vector as cross-evidence and applies an attention mechanism that increases weight where payer-side anomalies align with payee-side fan-out or device reuse. The combined estimate informs a preauthorization decision. If the composite score crosses a hold threshold, the payer bank can delay the outgoing transfer, trigger out-of-band verification with the originator, or cancel the instruction before settlement. If the score is elevated but not decisive, the payer may reduce the allowable amount, require a stronger authentication factor, or route the transaction to a secondary review queue. The configuration also permits iterative refinement. The payer bank can return a minimal acknowledgment to the payee, optionally containing hashed confirmations that allow the payee to record that the payer consumed the signals without exposing identities. For dispute resolution, both parties can retain cryptographic receipts that bind inputs and outputs by digest so that auditors can later confirm that the decision was based on the exchanged assessments. As with the other configurations, only hashed values cross institutional boundaries. Raw telemetry remains inside each bank. The result is a pre-debit safeguard that gives the payer bank a direct view of recipient-side posture at the time of decision, without violating privacy constraints or requiring a centralized service.

[0050] Some embodiments provide a method for detecting fraud in a financial transaction between two banks, comprising: (a) Bank A collecting and analyzing behavioral and biometric data of a user initiating a transaction to calculate a fraud-relatedness score or a financial crime relatedness score; (b) Bank B collecting and analyzing behavioral and biometric data of a recipient of the transaction to calculate its fraud-relatedness score or its financial crime relatedness score; (c) both banks sending their fraud-relatedness scores (or financial crime relatedness score) to a trusted third-party device; (d) the third-party device combining the scores to generate a unified fraud-relatedness score or a unified financial crime relatedness score; (e) each bank receiving the unified score and determining whether the score exceeds its threshold to take further action.

[0051] Some embodiments provide a method for collaborative fraud detection between financial institutions, comprising: (a) Bank A generating a fraud-relatedness score based on device and behavioral characteristics of a user; (b) Bank B generating a fraud-relatedness score based on device and behavioral characteristics of the recipient; (c) Bank A sending its fraud signals to Bank B directly; (d) Bank B combining these signals with its data to re-calculate the fraud-relatedness score; (e) Bank B taking action if the updated fraud-relatedness score exceeds a set threshold.

[0052] Some embodiments provide a method for preventing fraud in cross-bank transactions, comprising: (a) Bank A analyzing input interactions, device data, and transaction history of a user to detect anomalies; (b) Bank B analyzing similar data for the receiving party; (c) Bank A sending detected fraud signals to a trusted third-party device; (d) the third-party device matching these signals against a database of previous fraud cases; (e) the third-party device notifying Bank A if a high fraud risk is detected.

[0053] Some embodiments provide a method for detecting fraud in a banking network, comprising: (a) Bank A detecting unusual behavioral patterns in a transaction; (b) Bank B detecting suspicious account activity in the recipient account; (c) each bank sharing non-identifiable fraud signals to a trusted third-party; (d) the third-party aggregating fraud indicators to produce a combined fraud-relatedness score; (e) each bank deciding whether to approve or flag the transaction based on the combined score.

[0054] Some embodiments provide a method for real-time fraud detection in financial transfers, comprising: (a) Bank A analyzing device fingerprint and behavioral biometrics of the sender; (b) Bank B analyzing similar data for the recipient; (c) Bank A sharing its fraud signals directly with Bank B; (d) Bank B updating its fraud-relatedness score based on Bank A's data; (e) Bank B taking additional verification measures if the score surpasses a threshold.

[0055] Some embodiments provide a method for fraud prevention in banking transactions using shared risk assessment, comprising: (a) Bank A calculating a fraud score using biometric and behavioral data; (b) Bank B calculating a fraud score for the recipient based on similar data; (c) both banks transmitting their fraud scores to a third-party device; (d) the third-party device cross-referencing data with a fraud history database; (e) providing each bank with an adjusted score for final decision-making.

[0056] Some embodiments provide a method for fraud score adjustment in multi-bank transactions, comprising: (a) Bank A calculating a fraud-relatedness score based on the sender’s interaction data; (b) Bank B calculating a fraud-relatedness score based on the recipient’s data; (c) Bank A sending its score to Bank B directly; (d) Bank B adjusting its scorewith Bank A’s data; (e) Bank B deciding to halt the transaction if the combined score is above the threshold.

[0057] Some embodiments provide a method for preventing financial crime through interbank data sharing, comprising: (a) Bank A assessing fraud risk and / or financial crime risk based on the sender user behavior and device characteristics; (b) Bank B assessing fraud risk and / or financial crime risk based on the recipient’s behavior and device; (c) Bank A transmitting a fraud and / or financial crime signal to a trusted third-party device; (d) the trusted third-party device identifying fraud or financial crime trends based on historical data; (e) the trusted third-party device providing a combined fraud score (or a combined financial crime likelihood score) to both banks for further action (e.g., transaction freeze or hold; requirement to contact customer service or fraud department; requirement to answer security questions; requirement to authenticate via another authentication factor).

[0058] Some embodiments provide a method for cross-institutional fraud detection or financial crime detection in financial networks, comprising: (a) Bank A detecting abnormal usage patterns and calculating a fraud score; (b) Bank B calculating a fraud score for the receiver based on suspicious account behavior; (c) Bank A transmitting fraud signals to Bank B; (d) Bank B combining Bank A’s signals with its own to re-evaluate the fraud score; (e) implementing security measures if the score exceeds a predetermined threshold.

[0059] Some embodiments provide a method for reducing fraud risk in banking transactions, comprising: (a) Bank A using behavioral data to detect fraud in an outgoing transaction; (b) Bank B detecting suspicious activity in the recipient account; (c) both banks sending fraud scores to a smart network device; (d) the smart network device generating a unified score using machine learning analysis; (e) sending the unified score back to both banks for review and response based on risk level.

[0060] Some embodiments provide a method for real-time fraud detection in cross-bank transactions, comprising: (a) Bank A calculating a fraud-relatedness score based on behavioral biometrics and device data from the sender; (b) Bank B calculating a fraud-relatedness score using the recipient's account activity and network behavior; (c) Bank A sending its fraud signals directly to Bank B; (d) Bank B updating its fraud score based on Bank A’s data; (e) Bank B deciding to flag or halt the transaction if the adjusted fraud score exceeds a set threshold.

[0061] Some embodiments provide a method for collaborative fraud prevention in interbank financial transactions, comprising: (a) Bank A analyzing user behavior and interaction patterns to calculate a preliminary fraud score; (b) Bank B evaluating recipient behavior and transaction history for its own fraud score; (c) Bank A transmitting fraud signals directly toBank B to improve fraud assessment; (d) Bank B combining Bank A's signals with its own data to adjust the fraud score; (e) each bank deciding whether to approve or suspend the transaction based on the combined fraud score.

[0062] Some embodiments provide a method for detecting fraud in a financial network transaction without third-party intervention, comprising: (a) Bank A analyzing behavioral patterns and device characteristics to generate a fraud score; (b) Bank B analyzing similar data for the transaction’s recipient to create its own fraud score; (c) Bank A sending its detected fraud signals directly to Bank B; (d) Bank B incorporating Bank A’s signals into its fraud detection model to update its fraud score; (e) each bank determining whether the transaction should proceed or be placed on hold based on the updated fraud score.

[0063] Some embodiments provide a method for real-time fraud scoring in direct interbank data sharing, comprising: (a) Bank A calculating a fraud-relatedness score based on user’s input patterns and device attributes; (b) Bank B assessing the recipient’s account behavior and network characteristics to create its fraud score; (c) Bank A transmitting fraud indicators directly to Bank B; (d) Bank B integrating Bank A's indicators with its own score to refine the fraud risk assessment; (e) both banks independently deciding whether the transaction should be allowed or flagged for further review based on the refined score.

[0064] Some embodiments provide a method for enhancing fraud detection in inter-bank transactions, comprising: (a) Bank A calculating a fraud-relatedness score based on the sender's behavioral biometrics and device data; (b) Bank B calculating a fraud-relatedness score using the recipient’s behavior and account activity; (c) each bank sending its fraud score to a trusted third-party device; (d) the third-party device combining the scores and generating an adjusted fraud score; (e) each bank receiving the adjusted score and determining whether to suspend the transaction based on its own threshold.

[0065] Some embodiments provide a method for multi-bank fraud prevention with a third-party device, comprising: (a) Bank A analyzing the sender's interaction patterns to produce a fraud-relatedness score; (b) Bank B assessing the recipient's transaction history and behavior for its own score; (c) both banks transmitting their fraud signals to a trusted third-party device; (d) the third-party device aggregating fraud signals and producing a unified fraud-relatedness score; (e) each bank using the unified score to decide whether to flag or hold the transaction.

[0066] Some embodiments provide a method for detecting financial fraud through interbank collaboration with third-party support, comprising: (a) Bank A detecting anomalies in user behavior and generating a preliminary fraud score; (b) Bank B detecting potential risks in the recipient's account based on network and device data; (c) each bank sending its fraud scoreto a trusted third-party device; (d) the third-party device referencing historical fraud cases and adjusting the fraud score accordingly; (e) each bank receiving the adjusted score and determining whether the transaction should proceed.

[0067] Some embodiments provide a method for collaborative fraud risk assessment between banks using a third-party device, comprising: (a) Bank A calculating a fraud score based on user input patterns and device characteristics; (b) Bank B assessing the recipient's risk based on past account activity and behavior; (c) each bank transmitting its fraud-related signals to a trusted third-party device; (d) the third-party device analyzing and combining signals to generate a weighted fraud score; (e) each bank using the weighted score to independently determine whether to allow or flag the transaction.

[0068] Some embodiments provide a method for fraud detection in banking transactions using hashed identifiers, comprising: (a) Bank A calculating a fraud-relatedness score based on behavioral biometrics and generating a hashed identifier for the sender; (b) Bank B calculating a fraud-relatedness score based on recipient data and generating a hashed identifier for the recipient; (c) both banks sending their fraud scores and hashed identifiers to a trusted third-party device; (d) the third-party device cross-referencing hashed identifiers with a database of known fraud cases; (e) each bank receiving an updated fraud score from the third-party device and determining if the transaction should be flagged.

[0069] Some embodiments provide a method for improving fraud detection in cross-bank transactions with hashed identifiers, comprising: (a) Bank A analyzing user behavior and generating a fraud score and hashed account ID for the sender; (b) Bank B generating a fraud score and hashed account ID for the recipient; (c) both banks transmitting their fraud scores and hashed identifiers to a trusted third-party device; (d) the third-party device comparing the hashed values with stored identifiers from historical fraud incidents; (e) each bank receiving an adjusted fraud score and deciding if additional verification is required.

[0070] Some embodiments provide a method for inter-bank fraud prevention utilizing hashed values, comprising: (a) Bank A calculating a fraud score based on user biometrics and generating a hashed transaction ID; (b) Bank B calculating a fraud score for the recipient and generating its own hashed transaction ID; (c) each bank sending its fraud score and hashed transaction ID to a trusted third-party device; (d) the third-party device combining the scores and comparing hashed values against a fraud history database; (e) each bank reviewing the combined score to determine if the transaction should proceed.

[0071] Some embodiments provide a method for fraud detection in financial networks using hashed identifiers, comprising: (a) Bank A analyzing sender data to create a fraud scoreand hashed identifier; (b) Bank B analyzing recipient data to create its own fraud score and hashed identifier; (c) both banks transmitting their fraud scores and hashed identifiers to a trusted third-party device; (d) the third-party device cross-referencing the hashed identifiers with those in a known fraud registry; (e) each bank receiving the unified fraud score and deciding whether to suspend the transaction.

[0072] Some embodiments provide a method for real-time fraud detection in inter-bank transfers with hashed values, comprising: (a) Bank A generating a fraud score and hashed identifier for the sender based on device and behavioral data; (b) Bank B generating a fraud score and hashed identifier for the recipient based on account activity; (c) each bank transmitting its fraud score and hashed identifier to a trusted third-party device; (d) the third-party device comparing hashed values to those of entities involved in previous fraudulent transactions; (e) each bank using the combined fraud score to determine if additional fraud prevention measures are needed.

[0073] In some embodiments, Bank A or its website or mobile application or its banking system or its server, and / or Bank B or its website or mobile application or its banking system or its server, and / or the trusted third-party device (which may be a remote server), and / or the end-user device of the user (e.g., of User Adam and / or User Bob), may optionally utilize, include, perform and / or provide one or more of the components, units, operations and / or methods that are described in United States patent application publication number US 2024 / 0013225 Al, titled “Method, Device, and System of Detecting Mule Accounts and Accounts used for Money Laundering”, which is hereby incorporated by reference in its entirety.

[0074] In some embodiments, Bank B may share with Bank A, and / or with a trusted third-party, one or more of the following data-items with regard to the Payee (in Bank B): The maximum risk score (e.g., ATO score, mule account score, fraud-relatedness score) of the payee account as payee from the last N days; The maximum risk score (e.g., ATO score, mule account score, fraud-relatedness score) of the payee account as payer from the last N days; The number of days since the payee account was seen for the first time; The number of days since the payee account was seen as a payee; The number of days since the payee account was seen as a payer; The largest amount sent to the payee account in the last N days; The largest amount sent from the payee account in the last N days; The number of distinct accounts that the payee account paid to in the last N days; The number of distinct accounts that paid to the payee account in the last N days; The number of payments made to the payee account in the last N days; The number of payments made from the payee account in the last N days; The cumulativemonetary amount sent to the payee account in the last N days; The accumulative amount sent from the payee account in the last 7 days; the number of days that passed since the payee account was last seen by the system that checks fraud signals; the number of days that passed since the last Password Reset (or credentials reset) process was performed and / or was requested regarding the payee account; the number of times that a Password Reset (or credentials reset) process was performed and / or was requested regarding the payee account since its opening and / or in the past N days; the number of different devices from which the payee account was accessed in the past N days; the number of different IP addresses from which the payee account was accessed in the past N days; the number of different browsers and / or OS versions (or combinations thereof) from which the payee account was accessed in the past N days; the number of different geo-locations from which the payee account was accessed in the past N days (e.g., based on IP-based geo-location and / or cellular connectivity and / or Wi-Fi connectivity); the average (or median) time-length of engagement session of the payee with his bank account over the past N days; the shortest time-length of engagement session of the payee with his bank account over the past N days; the longest time-length of engagement session of the payee with his bank account over the past N days; the average (and / or maximum, and / or minimum) typing speed of the payee during engagements with its bank account in the last N days; and / or other data-items. In some embodiments, N may be a pre-defined positive number, such as 7 or 30 or 180. In some embodiments, the data may be provided with regard to two or more values of N; for example, providing the data for both N=7 and N=30 with regard to the payee.

[0075] In some embodiments, Bank A may share with Bank B, and / or with a trusted third-party, one or more of the following data-items with regard to the Payer (in Bank A): The maximum risk score (e.g., ATO score, mule account score, fraud-relatedness score) of the payer account as payee from the last N days; The maximum risk score (e.g., ATO score, mule account score, fraud-relatedness score) of the payer account as payer from the last N days; The number of days since the payer account was seen for the first time; The number of days since the payer account was seen as a payee; The number of days since the payer account was seen as a payer; The largest amount sent to the payer account in the last N days; The largest amount sent from the payer account in the last N days; The number of distinct accounts that the payer account paid to in the last N days; The number of distinct accounts that paid to the payer account in the last N days; The number of payments made to the payer account in the last N days; The number of payments made from the payer account in the last N days; The cumulative monetary amount sent to the payer account in the last N days; The accumulative amount sentfrom the payer account in the last 7 days; the number of days that passed since the payer account was last seen by the system that checks fraud signals; the number of days that passed since the last Password Reset (or credentials reset) process was performed and / or was requested regarding the payer account; the number of times that a Password Reset (or credentials reset) process was performed and / or was requested regarding the payer account since its opening and / or in the past N days; the number of different devices from which the payer account was accessed in the past N days; the number of different IP addresses from which the payer account was accessed in the past N days; the number of different browsers and / or OS versions (or combinations thereof) from which the payer account was accessed in the past N days; the number of different geo-locations from which the payer account was accessed in the past N days (e.g., based on IP-based geo-location and / or cellular connectivity and / or Wi-Fi connectivity); the average (or median) time-length of engagement session of the payer with his bank account over the past N days; the shortest time-length of engagement session of the payer with his bank account over the past N days; the longest time-length of engagement session of the payer with his bank account over the past N days; the average (and / or maximum, and / or minimum) typing speed of the payer during engagements with its bank account in the last N days; and / or other data-items. In some embodiments, N may be a pre-defined positive number, such as 7 or 30 or 180. In some embodiments, the data may be provided with regard to two or more values of N; for example, providing the data for both N=7 and N=30 with regard to the payer.

[0076] In accordance with some embodiments, the system is operated by (or utilizes) a smart network, which transfers information between financial institutions in a manner that complies with regulatory requirements and confidentiality / privacy constraints. The network is “smart” because in addition to collecting, keeping and sharing data, it processes the information and uses algorithms to create risk-based decisions, as described below.

[0077] (a) The smart network collects, generates, and stores behavioral and non-behavioral signals during online interactions of users with their banks. Signals include mouse movement and clicks, keyboard events, touch-screen events, device sensors data (gyroscope, accelerometer, compass unit, device orientation / slanting / tilt), device characteristics, and geographic location (e.g., based on IP address and / or other information).

[0078] (b) The smart network uses these signals to calculate the user’s probabilities of being involved in fraud, as a victim (Account Takeover risk score or ATO risk score, AO risk score, “vishing” attack risk score) or as a recipient (“mule” risk score). This is done by learningfrom historical confirmed fraud cases, which are used to train Machine Learning / Deep Learning models that predict to estimate risks following each interaction.

[0079] (c) In each transaction, the sending bank provides to the smart network at least the following information: a hashed account ID, a hashed payer value, a hashed payee value, and payment amount. Additional information may be provided to further enrich the smart network.

[0080] (d) The smart network uses the payee information to map it to a user that was seen in the smart network (e.g., as a payer having the same value; or, in some embodiments or scenarios, as a payee having the same value).

[0081] (e) In response to the information that the sending bank provides, the smart network shares with the sending bank information about risks that the network previously calculated with regard the receiving account. These may include risk scores that reflect the probability that the payee was involved in an account takeover attempt (as a payer or as a payee), the probability that the user’s account is being accessed using a Remote Access module or an automated script or a VPN or s proxy server, the probability that the account is involved in a social engineering scam (as a payer or as a payee), the probability that the account is a money laundering or “mule” / pipeline account, or other signals or scores or probability values. In addition, the smart network may share data points that describe stored information about the receiving account. Such data points may include a “payee age”, which reflects the time that passed since the first time in which the receiving account was seen in the network, a flag that indicates if the account was recently dormant, and a flag that indicates if the account was reported as a confirmed bad actor.

[0082] (f) In some cases, even if the payee value that the sending bank provides cannot be mapped to a user, then the smart network can still provide available and relevant data points. For example, if the receiving bank is not part of the smart network, the network still “knows” when the payee value was first seen and can provide a payee age accordingly.

[0083] (g) In some implementations, the smart network can also share data with the receiving bank. For example, if there is an extreme risk that the transaction is an account takeover attempt, then the smart network may notify the receiving bank about a high-risk inbound payment / incoming payment, so that the money will not leave the receiving account until further investigation.

[0084] (h) In some implementations, the smart network can create a multi-dimensional risk indication or score, which gathers all available information about: (1) the payer’s user profile, (2) the payee’s user profile, and (3) a cross analysis of both. For example, if in a specific payment from User Adam to User Bob, (i) the risk for account takeover (based on theinformation that the smart network keeps about User Adam) is medium-to-high, and also, (ii) the risk that the receiving account is a money laundering “mule” account is medium-to-high (based on what the information that the smart network keeps about User Bob), and also, (iii) the two accounts are accessed using the same device and / or their usage sessions exhibit the same behavioral patterns or characteristics (e.g., same or similar usage or non-usage of keyboard shortcuts, typing speed, typing rhythm, mouse usage patterns, touchpad usage patterns, touch-screen usage patterns, or the like), then: the smart network can indicate that the total multi-dimensional risk for this transaction is very high, because the data suggests or indicates that it is plausible that a bad actor is moving money from a victim’s account to an account which is operated by the bad actor.

[0085] Some embodiments provide systems and methods for real-time fraud detection and financial crime prevention in financial networks using behavioral biometrics. Some embodiments may provide digital fraud detection and prevention in financial networks, including methods for detecting malicious activities such as operating “mule” bank accounts, account takeover, and social engineering.

[0086] The Applicant has realized that conventional systems often lack the real-time capability and accuracy needed to prevent fraud effectively based on cross-bank information.

[0087] The Applicant has realized that financial institutions face increasing challenges in detecting sophisticated forms of fraud, due to the rapid growth of online banking and payment systems. Traditionally, fraud detection systems rely on rule-based systems that are often too static and inefficient at adapting to new types of fraud and to new attacks.

[0088] Some embodiments of the present invention may employ methods for monitoring transaction amounts, account history, or geographic locations. However, realized the Applicant, traditional methods may fail to detect fraudulent behaviors like utilization of a “mule” bank accounts, where legitimate accounts are used by criminals (e.g., as a pipeline or a transitory account) for illicit purposes or illegal goals. Furthermore, realized the Applicant, banks lack real-time information about the riskiness of devices and / or accounts and / or users in (or of) other banks. This translates into failure of traditional systems to detect fraud attempts in cross-bank transfers.

[0089] The Applicant has realized that there is a need for a system that can continuously monitor behavioral patterns within accounts, providing real-time insights based on a more comprehensive and proactive approach to fraud detection.

[0090] Some embodiments of the present invention provide a real-time behavioral analytics-based fraud detection system, specifically tailored to financial networks, with thecapability of detecting fraudulent patterns and behaviors across multiple accounts and crossbank accounts / cross-bank users. The system analyzes historical and / or current and / or realtime transaction data and / or usage patterns and / or user interaction patterns, identifying one or more patterns that are pre-defined as being associated with fraudsters, criminals, hackers, attackers, mule accounts, and other malicious activities.

[0091] Some embodiments may provide the following features: (1) Continuous Data Analysis, as the system continuously monitors internal and external financial transfers, as well as login activity, analyzing data in real time to detect fraudulent patterns. (2) Behavior-Enhanced Fraud Detection, as the system’s models learn from historical fraud cases and are capable of identifying suspicious activity based on behavioral inconsistencies, such as sudden changes in transaction types, location of transfers, and device profiles. (3) Fraud Scores generation and utilization, as multiple risk factors are detected / analyzed, resulting in generation of risk indicators / risk signals / a risk score / a fraud-relatedness score, that reflects the likelihood of an account being involved in fraud and / or the likelihood that a particular transaction is fraud-related. These scores may include, for example, a mule account likelihood score, ATO score, and social engineering score. (4) Collaborative Data Network, as system enables cross-institutional collaboration, wherein fraud data is shared between participating financial institutions to improve detection accuracy.

[0092] The system is structured as a distributed network of connected financial institutions, each of which participates by sharing transactional and behavioral data. The network is constantly monitored by a centralized analysis engine, which performs both real-time and historical analysis.

[0093] In some embodiments, Data Sources and Signal Generation may be performed. For example, the system collects and processes several key data types: (1) Transaction Metadata, such as information of the sender’s account ID, recipient account ID, transaction amount, and timestamps; these are collected from each transaction, and optionally their hashed values may be shared with a central server or with other institutions. (2) Device Profiles, which reflect device-specific data such as IP addresses, browser fingerprinting, installed fonts, OS type and version, browser type and version, installed drivers / extensions / add-ons / plus-ins, and location data, which can be used to detect device -related anomalies. (3) Behavioral Biometrics, or behavioral patterns such as typing cadence, typing rhythm, mouse movements, and interaction frequency are tracked for each account holder to build a behavioral profile. (4) Fraud Case Data, including historical data of confirmed fraud cases that are stored in a centralized database and used to train the fraud detection algorithms.

[0094] The system can be configured to perform Behavioral-Based Risk Scoring. For example, each transaction is evaluated based on behavioral metrics of the sending and the receiving accounts, and scores are assigned to the accounts accordingly. Some demonstrative scores that can be generated are: (1) Mule Likelihood Score, as the system evaluates whether an account is acting as a mule for illicit activities. Indicators such as inconsistent transaction patterns, unusual fund flow, or connections to known fraudulent accounts contribute to the mule score. (2) Account Takeover (ATO) Likelihood Score, as the system tracks the likelihood of an account being compromised, with specific attention to abnormal login patterns, such as logins from new devices, rapid geographic shifts, or unusual transaction volumes. (3) Social Engineering Likelihood Score, as accounts are assessed for susceptibility to social engineering attacks, particularly those where accounts transfer funds to previously flagged fraudulent destinations. (4) Device Fingerprinting, as the system tracks the behavioral and environmental footprint of devices used to access accounts; if a bad actor gains control of an account from a different device, the change is flagged.

[0095] Some embodiments perform Real-Time Detection and Alerts. The system operates in real-time, continuously updating fraud scores based on recent activities. When the system identifies a suspicious transaction, it sends a real-time alert to the participating financial institutions. Alerts can trigger a variety of responses, including transaction holds, account freezes, or further investigative measures.

[0096] Some embodiments train and utilize Machine Learning (ML) / Deep Learning (DL) Algorithms. For example, the system uses ML / DL models that are trained on a wide array of behavioral and transactional data. These models are continuously updated with new fraud cases, enabling the system to adapt to emerging fraud tactics. Supervised learning models are used for known fraud patterns, trained on historical data such as confirmed mule accounts or compromised devices. Unsupervised learning may be applied for anomaly detection, helping identify new and evolving types of fraud before they become widespread.

[0097] Example Use Case 1: Mule Account Detection. An individual opens an account at Participating Bank A, and two years later, following a high-amount inbound transfer, begins transferring funds to multiple accounts across different regions. The system detects a sudden increase in activity that is inconsistent with the individual’s previous behavior, and assigns a high mule likelihood score. Based on the score, Participating Bank A blocks the transactions and notifies its fraud department and / or law enforcement for further investigation. Additionally, Participating Bank B is informed in real-time for an attempt of an account in the bank to send funds to the flagged account.

[0098] Example Use Case 2: Account Takeover (ATO) Detection. A large wire transfer is performed from an account at Participating Bank C using a new device, Device 1. The system assigns a high ATO likelihood score due to the inconsistency with the account holder’s previous behavior. Participating Bank C flags the account and prevents the transaction, prompting the customer to verify their identity. An hour later, an account at Participating Bank D is accessed using Device 1. The system notifies bank D that this account is at risk, or may be involved in a fraudulent transaction, or may be compromised.

[0099] Some embodiments may provide some or all of the following benefits. (1) Enhanced Fraud Detection, as by focusing on behavioral data and device profiles, the system is better equipped to detect sophisticated fraud tactics that traditional rule-based systems miss. (2) Reduced “False Positive” Errors, as the behavioral nature of the system allows it to differentiate between genuine and fraudulent transactions, reducing the number of false positives and improving customer experience. (3) Real-Time Protection, as the system’s real-time analysis capabilities ensure that fraudulent activities are detected as they happen, preventing losses before they occur. (4) Cross-Institutional Collaboration, as by sharing fraud data across multiple financial institutions, the system creates a super-informative network effect that enhances detection accuracy. Some embodiments may thus provide a robust, real-time fraud detection / prevention / mitigation system that uses cross-institutional network data, behavioral analytics and machine learning to detect and prevent various forms of financial fraud. It enhances the security of financial networks by continuously monitoring accounts and transactions, providing real-time fraud scores and alerts to participating institutions.

[0100] In some embodiments, the system may provide a federated, inter-institution payment-risk trust network that enables privacy-preserving entity resolution and cross-bank intelligence sharing prior to funds movement. A server computing device operated by a network coordinator receives, from a plurality of financial institutions, structured requests containing cryptographically transformed payer and payee identifiers, each produced by a deterministic, collision-resistant hashing function, such as SHA-256, optionally with institution-specific or network-provided salts. The coordinator normalizes payloads to a canonical schema, validates message integrity, and performs linkage across hashed identifiers, device fingerprints, and historical transaction artifacts to construct participant profiles that are not directly reversible to personally identifiable information. The coordinator computes, in real time, a transaction-level trust metric using a supervised or hybrid model that ingests both sender session telemetry and receiver profile attributes sourced from the receiving institution, with temporal decay and jurisdictional policy constraints applied to feature access. The trust metricis serialized as a bounded integer and returned to the requesting institution over a mutually authenticated, encrypted transport prior to irrevocable payment execution. The network supports idempotent request semantics, replay protection, and fine-grained access controls that restrict field visibility by role, use case, and applicable regulation. In some variations, the coordinator publishes cross-institution risk attributions, typology indicators, and confidence intervals while enforcing k-anonymity floors to prevent deanonymization. The system further records immutable audit events for each scoring decision to satisfy model-risk governance, provides versioned feature dictionaries to all participants, and exposes a deterministic fallback pathway when receiver intelligence is unavailable. By abstracting identity through standardized hashed fields, the trust network enables high-fidelity cross-bank risk inference without exchanging raw account numbers, thereby reducing data custody risk while materially improving first-party scam and mule detection at authorization time.

[0101] Some embodiments may provide a method for computing privacy-preserving crossbank transaction trust scores within a federated network, the method comprising: (a) receiving, from a requesting institution, payer and payee identifiers hashed with a deterministic collisionresistant function and optional rotating salt; (b) validating payload schema, timestamps, and idempotency keys, and normalizing fields to a canonical network schema with partner attribution metadata; (c) linking hashed identifiers to institution-agnostic participant profiles using device fingerprints, historical transaction graphs, and temporal decay functions; (d) extracting sender session telemetry and receiver profile attributes allowed under jurisdictional feature gating policies; (e) inferring a transaction trust metric using a supervised model and serializing the metric as a bounded integer; (f) returning the metric to the requester over mutually authenticated encrypted transport prior to irrevocable payment execution.

[0102] Some embodiments may provide a method for coordinating inter-institution intelligence for scam and mule detection without exchanging raw account numbers, the method comprising: (a) establishing a network coordinator that enforces canonical schemas, partner authentication, replay protection, and role-based field-level access controls; (b) receiving standardized scoring requests containing hashed payer and payee account identifiers, activity amount, account open date, and channel context; (c) resolving cross-bank linkages by matching hashed identifiers, device lineages, and counterparty graphs while maintaining k-anonymity thresholds; (d) computing real-time trust scores using models trained on labeled fraud typologies and permitted feature families; (e) persisting signed, tamper-evident audit logs containing request identifiers, model versions, and decision artifacts; (f) transmitting trustscores and attribution summaries to the originating institution for pre-authorization decisioning within latency objectives.

[0103] In some embodiments, the system may provide a dual-path transactional risk evaluation architecture that dynamically selects a mapped or non-mapped inference pipeline conditioned on whether a receiver account can be deterministically associated with a known user profile within a vendor or network directory. Upon receipt of a scoring request, an orchestration layer computes a receiver mapping signal by joining the hashed receiver account identifier with a directory of user profile keys, employing exact-match and configurable secondary joins across auxiliary identifiers, including device bound tokens, payment handles, and institution-scoped aliases. When a positive mapping is established, the mapped pipeline activates a model class that consumes features drawn from both sender and receiver user profiles, including cross-session behavior aggregates, device lineage, historical counterparty relationships, and prior adjudication outcomes, with sampling weights calibrated to reflect asymmetric fraud base rates. When no mapping is found, the non-mapped pipeline activates an alternative model class that suppresses unavailable receiver user fields, emphasizes sender session dynamics, and incorporates receiver-account attributes supplied by the receiving institution, such as account age, recent inflow patterns, and velocity controls. The architecture enforces a suppression rule for intra-user transfers, where sender and receiver resolve to the same user identifier, by bypassing risk scoring or issuing a low-risk code path. Pipeline selection, feature availability masks, and downstream calibration parameters are versioned and logged to guarantee reproducibility. The system supports online switching with health checks, monitors for mapping drift, and triggers retraining or threshold recalibration when the proportion of mapped traffic deviates beyond configured tolerances, thereby maintaining stable alert volumes and consistent decision quality across heterogeneous receiver visibility conditions.

[0104] Some embodiments may provide a method for dynamic pipeline selection between mapped and non-mapped receiver states, the method comprising: (a) calculating a receiver mapping signal by joining hashed receiver identifiers against a directory of user profile keys; (b) selecting a mapped model pipeline when a deterministic association between the receiver account and a user profile exists; (c) selecting a non-mapped model pipeline when no valid association exists after auxiliary identifier checks and time-bounded joins; (d) ingesting sender features, receiver features when available, and receiving-bank account attributes with masking of unavailable fields; (e) suppressing risk scoring when sender and receiver resolve to the sameuser identifier indicating an intra-user transfer; (f) logging pipeline selection, feature masks, and inference metadata for reproducibility and governance review.

[0105] Some embodiments may provide a method for risk scoring transactions using receiver visibility segmentation, the method comprising: (a) receiving a scoring request with hashed payer and payee identifiers, channel metadata, and idempotency information; (b) attempting deterministic mapping of the payee account to a vendor user profile using primary and secondary keys; (c) routing the request to a mapped model when mapping succeeds, otherwise routing to a non-mapped model; (d) generating features from sender sessions and inbound receiver account attributes, applying feature availability masks; (e) producing calibrated scores under pipeline-specific calibration artifacts and policy identifiers; (f) emitting structured outputs including pipeline classification, score, band, and correlation identifiers to downstream decision engines.

[0106] In some embodiments, the system may provide a feature engineering and enrichment framework that transforms heterogeneous session telemetry and partner-supplied account attributes into structured, model-ready feature families that capture deception, obfuscation, and coordinated fraud typologies across web, mobile, and API channels. A feature service ingests raw signals including pointer-level interaction traces, dwell times, input cadence vectors, viewport and focus transitions, device and OS metadata, browser fingerprint components, locale and time zone coherence, geolocation and network characteristics, and indicators of anomalous technical proficiency such as instrumentation fingerprints, automation signatures, or headless browser artifacts. The service performs temporal aggregation at multiple windows, computes statistical moments and entropy measures, derives sequence embeddings or n-gram encodings of interaction tokens, and applies normalization, winsorization (replacing or discarding extreme values to mitigate the influence of outlier values), and rare -category handling to produce stable inputs. Concurrently, an inbound payee feature adapter accepts receiving-bank attributes, such as account tenure, inbound transfer velocity, beneficiary dispersion, return rates, and recent negative event flags. All features are compiled under a versioned dictionary with explicit data types, ranges, imputation policies, and provenance tags. The framework supports per-jurisdiction feature gating, differential sampling for high-cardinality categorical variables, and monotonic constraints for selected risk indicators when used with gradient boosted decision trees. Feature outputs are cached with short time-to-live semantics for online scoring, while historical snapshots are persisted with event time stamps for training and audit. The system validates feature integrity through distributional tests, PSI monitoring, and canary scoring, automatically quarantining sources that exhibit capture failuresor adversarial manipulation signatures, thereby preserving model reliability in adversarial and non-stationary environments.

[0107] Some embodiments may provide a method for constructing multi-family features from heterogeneous telemetry for fraud detection, the method comprising: (a) ingesting raw behavioral interaction traces, dwell times, input cadence vectors, and focus transitions from client sessions; (b) collecting device, operating system, browser fingerprint components, locale, time zone, IP network traits, and coarse geolocation; (c) deriving statistical moments, entropy measures, sequence embeddings, and n-gram encodings over interaction tokens across sliding temporal windows; (d) integrating receiving-bank attributes including account tenure, transfer velocities, beneficiary dispersion, and negative event flags; (e) normalizing, winsorizing, imputing, and rare-category pooling features under a versioned dictionary with provenance; (f) caching low-latency feature views for online scoring and persisting event-time snapshots for training and audit.

[0108] Some embodiments may provide a method for safeguarding feature integrity against capture failures and adversarial manipulation, the method comprising: (a) running schema validation and distributional checks on incoming telemetry streams across behavioral, device, browser, localization, and expertise indicators; (b) computing population stability indices and divergence metrics relative to reference distributions for each feature family; (c) quarantining degraded or compromised feature sources and substituting deterministic fallbacks with conservative priors; (d) enforcing per-jurisdiction feature gates and monotonic constraints for selected indicators; (e) recording feature lineage, transformation parameters, and data quality flags alongside inference artifacts; (f) initiating canary scoring and escalation workflows when drift thresholds or integrity alarms exceed configured tolerances.

[0109] In some embodiments, the system may provide a calibrated risk scoring layer that converts raw model outputs into an operational 1 -to- 1,000 integer scale aligned to pre-defined alert-rate bands and institution- specific decision policies. A calibration service receives unbounded classifier logits or probability estimates and applies a selected calibration method, such as isotonic regression or Platt scaling with cross-validated folds, fitted on temporally separated validation sets to mitigate leakage. The resulting calibrated probabilities are then mapped to a fixed integer range using a monotonic, piecewise-linear transform that preserves ordering while avoiding floating-point serialization. Band boundaries are configured to target stable alert rates under expected traffic mix, with guardrails that automatically re-optimize bin edges within compliance-approved tolerances when input distributions drift. The service computes and returns auxiliary diagnostics, including per-band historical detection rates,expected investigation volumes at threshold candidates, and confidence intervals derived from bootstrap resampling. Decision policies, including hard block, step-up authentication, customer education interstitials, and post-transaction monitoring, reference band membership rather than continuous scores to simplify control logic and facilitate change management. The calibration artifacts are versioned, signed, and atomically deployed with the underlying model to ensure score continuity through model updates. In resiliency scenarios, the service can degrade gracefully to prior calibration maps or to a conservative static policy, thereby maintaining predictable operational load on fraud operations teams while sustaining high precision in the top risk deciles.

[0110] Some embodiments may provide a method for calibrating model outputs to a fixed 1 -to- 1,000 operational scale, the method comprising: (a) receiving raw classifier logits or probabilities from a production inference service; (b) applying an approved calibration method trained on temporally separated validation data to obtain calibrated probabilities; (c) mapping calibrated probabilities to an integer scale using a monotonic piecewise function preserving order; (d) assigning band memberships according to configured alert-rate targets and institution policies; (e) computing expected investigation volumes, historical detection rates, and confidence intervals per band; (f) returning score, band, policy version identifiers, and diagnostics to downstream decision controllers.

[0111] Some embodiments may provide a method for maintaining stable alert volumes through adaptive calibration governance, the method comprising: (a) monitoring score distributions, band occupancy, and adjudicated outcomes over rolling windows; (b) detecting distributional drift and band instability using statistical process control tests and bootstrap intervals; (c) re-optimizing band edges within compliance-approved tolerances to sustain target alert rates; (d) atomically deploying updated calibration artifacts alongside model versions with signature verification; (e) reverting to previous calibration maps upon health-check failures or excessive variance; (f) documenting changes, rationales, and observed impacts within tamper-evident governance records.

[0112] In some embodiments, the system may provide a standardized, secure requestresponse interface for real-time scoring that enforces a canonical API contract, input validation, and transport-level protections appropriate for regulated financial data. A scoring endpoint, exposed over mutually authenticated TLS, accepts JSON or Protocol Buffers payloads containing required fields including trustAccountld, trustPayerld, trustPayeeld, accountOpenDate, activity Amount, and payeeBankCode, along with optional context such as channel type, device key, session identifiers, and prior authentication outcome. Account anduser identifiers are provided as cryptographic hashes generated by a deterministic algorithm, with optional per-partner or per-environment salts rotated on a governed cadence. The endpoint performs schema validation, semantic checks on temporal fields and amounts, and enforces idempotency via a caller-supplied idempotency key with replay detection. Payloads are normalized to internal types, truncated at configured maxima, and annotated with ingestion metadata, including reception time, API version, and partner identifier. Responses include a calibrated risk score, band designation, decision recommendation, policy version identifiers, and correlation IDs to support downstream case management and audit. The interface exposes deterministic error codes for validation failures, controlled redactions for sensitive fields, and rate limiting with token bucket semantics to preserve service quality. All messages are logged to a tamper-evident store with cryptographic hashes to satisfy evidentiary requirements, while secrets and keys are managed by a hardware-backed vault service with role-based access controls and short-lived tokens. The design yields consistent, low-latency scoring while minimizing data custody risk and enabling straightforward partner integration.

[0113] Some embodiments may provide a method for secure real-time scoring via a canonical API, the method comprising: (a) exposing a mutually authenticated TLS endpoint accepting JSON or Protocol Buffers requests; (b) validating required parameters including trustAccountld, trustPayerld, trustPayeeld, accountOpenDate, activityAmount, and payeeBankCode; (c) enforcing idempotency through caller-supplied keys and rejecting replays beyond configured windows; (d) normalizing payloads to internal types, truncation limits, and semantic constraints; (e) generating calibrated risk scores, band designations, and decision recommendations with correlation identifiers; (f) transmitting responses and persisting cryptographically signed audit logs with minimal necessary sensitive data retention.

[0114] Some embodiments may provide a method for privacy-preserving identifier handling within scoring interfaces, the method comprising: (a) generating deterministic cryptographic hashes over account and user identifiers using approved collision-resistant algorithms; (b) rotating salts under governed schedules and partner scopes to reduce linkage exposure; (c) limiting raw identifiers to caller premises while transmitting only hashed fields to the scoring service; (d) performing schema and temporal sanity checks prior to acceptance; (e) associating metadata including API version, partner identifier, and reception timestamp; (f) storing request artifacts within encrypted tamper-evident stores subject to role-based retrieval controls.

[0115] In some embodiments, the system may provide data quality management and preprocessing controls that stabilize model development and online inference underheterogeneous, incomplete, or adversarial inputs. A preparation pipeline executes a sequence of deterministic treatments including missing value resolution via domain-specific defaults or sentinel categories, quantile-based binning of skewed continuous variables, categorical encoding with rare-level pooling, and outlier mitigation through percentile capping or Huberization. The pipeline performs de-duplication using composite keys spanning device, session, and event time, reconciles contradictory records, and aligns event timestamps to a canonical clock with drift detection. Feature transformations are computed under a versioned recipe that records upstream lineage and parameter values, enabling exact regeneration of training matrices and forensic reproduction of online feature vectors. For model training, the system filters sessions with structural capture failures, known hot floods, or corrupted telemetry to avoid biasing parameter estimates, while preserving representative genuine traffic via stratified sampling. During online scoring, the same recipe is executed in a low-latency feature service that applies identical mappings and caps, emitting per-field quality flags consumed by a policy engine to decide on fallback strategies or human review. Distributional shift is monitored through PSI, JS divergence, and drift detectors on a rolling basis, with automated escalation when thresholds are crossed. All transformations are unit tested, schema enforced, and protected against injection and high-cardinality explosions, thereby ensuring robust, reproducible inputs across the model lifecycle.

[0116] Some embodiments may provide a method for preparing model-ready data under deterministic preprocessing controls, the method comprising: (a) imputing missing values using domain- specific defaults or sentinel categories recorded within a versioned recipe; (b) binning skewed continuous variables via quantile schemes and capping outliers by percentile thresholds; (c) encoding categorical variables with rare-level pooling to control cardinality; (d) de-duplicating sessions through composite keys spanning device, session, and event time; (e) aligning event timestamps to a canonical clock and detecting drift; (f) generating identical online and offline transformations to ensure reproducible training and inference.

[0117] Some embodiments may provide a method for online inference with data quality awareness, the method comprising: (a) executing the same transformation recipe used during training within a low-latency feature service; (b) emitting per-field quality flags when imputations, caps, or rare pooling are applied; (c) routing degraded requests to fallback policies or human review based on quality thresholds; (d) monitoring rolling stability metrics including PSI and divergence across critical features; (e) triggering alerts and protective throttles upon threshold breaches; (f) recording transformation parameters and quality signals with inference outputs for downstream audit.

[0118] In some embodiments, the system may provide a supervised training and validation protocol that incorporates institution-specific fraud feedback, temporal hold-outs, and stability testing to ensure generalization to evolving attack patterns. A labeling service aggregates confirmed fraud events across typologies, including authorized push scams, first-party mule activity, synthetic identities, and account takeovers, and reconciles these with transaction sessions through deterministic joins and time-bounded heuristics. Positive labels are exhaustively collected for the development window, while genuine examples are randomly sampled with stratification across channels, device families, and receiver mapping status to preserve operational priors. The training split reserves the most recent labeled period as a holdout validation set, preventing leakage and providing a realistic measure of current-pattern performance. The selected learner, such as gradient boosted decision trees with monotonic constraints, is trained with cost-sensitive loss, class weighting, and hyperparameters tuned via nested cross-validation. After validation, a final model is refit on the full development set and evaluated on an out-of-time test set to quantify prospective stability. Model cards can document feature importance values, partial dependence plots, subgroup analyses, and fairness diagnostics. All artifacts, including code, data manifests, and random seeds, are versioned in a model registry. The protocol supports periodic retraining triggers based on drift metrics, KPI degradation, or partner change requests, enabling disciplined, auditable updates under modelrisk management.

[0119] Some embodiments may provide a method for supervised model development using time-aware validation, the method comprising: (a) aggregating institution-specific confirmed fraud labels across typologies and reconciling them to sessions with deterministic joins; (b) sampling genuine traffic with stratification across channels, device families, and receiver mapping states; (c) reserving the most recent labeled period as a hold-out validation set to reduce leakage; (d) training a learner with cost-sensitive loss, class weighting, and monotonic constraints; (e) refitting on full development data and evaluating out-of-time stability; (f) registering artifacts, metadata, and seeds within a governed model registry.

[0120] Some embodiments may provide a method for lifecycle governance and retraining triggers, the method comprising: (a) tracking key performance indicators including precision, recall, and alert rates on adjudicated cases; (b) computing drift metrics over features and outputs with configured windows and baselines; (c) initiating retraining when KPI degradation or drift thresholds are exceeded; (d) executing change control including documentation, approvals, and rollback plans; (e) deploying updated models with atomic calibrationsynchronization; (f) publishing model cards summarizing features, fairness diagnostics, and limitations to stakeholders.

[0121] In some embodiments, the system may provide production monitoring, service health, and governance workflows that detect data and performance anomalies early, enforce escalation playbooks, and maintain regulatory compliance. A telemetry layer records end-to-end metrics including request volumes, latency distributions, error rates by code, upstream endpoint availability, and cache hit ratios, while a model observability layer tracks score distributions, band occupancy, alert rates, precision and recall on adjudicated cases, and data integrity signals at the feature and family levels. Control charts, drift indices, and seasonal baselines generate alerts when metrics exceed configured thresholds or violate learned patterns. An incident workflow automatically assembles context, including recent deployments, configuration diffs, and traffic mix changes, and routes to responsible roles in threat analytics, data science, site reliability, or partner operations. The workflow supports temporary containment actions, such as threshold adjustments or traffic throttling, and documents decisions with time stamps and approvers for audit. Periodic reviews produce governance reports that summarize performance, false positive burdens, customer impacts, and remediation actions, satisfying model-risk and internal audit requirements. Access to dashboards and raw telemetry is role-segmented, with PII redaction and tokenization enforced, and all monitoring code is tested and versioned alongside the model to ensure consistent behavior across environments.

[0122] Some embodiments may provide a method for production monitoring and incident response for a fraud detection service, the method comprising: (a) collecting telemetry for request volumes, latency percentiles, error codes, endpoint availability, and cache utilization; (b) observing model behavior via score distributions, band occupancy, and performance on adjudicated samples; (c) evaluating control charts and anomaly detectors for deviations against seasonal baselines; (d) assembling incident context including recent deployments, configuration diffs, and traffic mix changes; (e) implementing temporary containment actions such as threshold adjustments or traffic throttling; (f) documenting actions, approvers, and outcomes within audit repositories.

[0123] Some embodiments may provide a method for governed reporting and access control over observability data, the method comprising: (a) generating periodic governance reports summarizing precision, false positive burdens, customer impacts, and mitigations; (b) segmenting dashboard and data access by role with tokenized or redacted sensitive fields; (c) versioning monitoring configurations and alert rules alongside model artifacts; (d) testingobservability code and validating metric integrity before promotion; (e) retaining telemetry under compliant retention policies with cryptographic integrity protections; (f) enabling reproducible post-mortems through correlated identifiers linking requests, scores, and operational actions.

[0124] In some embodiments, the system may provide a controlled override and rapidresponse mechanism that allows authorized analysts to introduce temporary, rule-based adjustments to the calibrated risk score or decision policy during emergent fraud events while preserving auditability and minimizing unintended collateral impact. A policy engine exposes a constrained domain-specific configuration language that supports declarative conditions on high-confidence indicators, including specific device fingerprints, network ASNs, automation signatures, receiver clusters, or velocity patterns, and assigns additive or multiplicative score adjustments, band escalations, or hard blocks for a bounded duration. Overrides are subject to multi-party approval, automatic expiry, and pre-deployment simulation against recent traffic to estimate precision and impact. At runtime, the override layer executes after model calibration and before action selection, publishing attribution metadata that identifies which rule contributed to the outcome. The system logs every evaluation with rule identifiers, parameter values, and effect sizes, enabling post-event analysis and governance review. When override efficacy diminishes or adverse effects are detected, the engine supports staged rollbacks. In parallel, data science initiates accelerated retraining or feature augmentation to internalize the emergent pattern into the learned model, allowing the override to be retired. This design enables fast containment of novel attacks without sacrificing the integrity and transparency of the primary machine-learning-driven decisioning process.

[0125] Some embodiments may provide a method for controlled rule-based overrides during emergent fraud events, the method comprising: (a) exposing a constrained configuration language enabling declarative conditions over high-confidence indicators; (b) assigning additive or multiplicative score adjustments, band escalations, or hard blocks with bounded durations; (c) requiring multi-party approvals and simulation against recent traffic before activation; (d) executing overrides after calibration and before action selection with attribution metadata; (e) monitoring precision and collateral impact to determine continued applicability; (f) rolling back overrides when efficacy diminishes and initiating accelerated model updates.

[0126] Some embodiments may provide a method for integrating rapid-response policies with machine-learned decisioning, the method comprising: (a) detecting novel attack patterns through spikes in specific fingerprints, autonomous system numbers, or receiver clusters; (b) drafting provisional override rules targeting discriminative indicators and intended risk bands;(c) estimating operational impact via offline replay and counterfactual evaluation; (d) deploying approved overrides with automatic expiry times and staged rollout; (e) capturing comprehensive logs including rule identifiers, parameter values, and effect sizes; (f) retiring overrides once updated models internalize patterns, restoring standard scoring behavior.

[0127] In some embodiments, the system may provide a real-time, inter-institution early-warning control that evaluates any contemplated digital payment prior to irrevocable execution and propagates structured risk intelligence to both the originating and receiving institutions for coordinated interdiction. A request from the sender’ s bank triggers concurrent inferences over the originator session to detect account-takeover signatures and social-engineering patterns while a parallel lookup estimates mule propensity for the named recipient, with the combined result computed within latency targets suitable for pre-authorization holds. The control emits machine -readable indicators to counterparties, including notifications to the receiving bank for high-risk inbound payments covering both processed and declined attempts, thereby enabling step-up verification, just-in-time blocks, or post-event containment if execution proceeds. The network operates continuously and at scale, matching a large share of national payments, while preserving normal user experience for legitimate traffic. The early-warning logic is designed to surface nuanced scam flows that are typically invisible to single-bank telemetry, by fusing sender-side ATO and scam likelihood with recipient-side mule likelihood and session overlap analytics. Outputs integrate with incumbent fraud platforms through APIs and event feeds, with idempotent semantics and replay protection, so downstream policy engines can test thresholds, reason over attribution, and record immutable audit artifacts for enforcement review. This architecture materially reduces loss exposure by enabling action at the only universally available control point, namely prior to funds movement, while distributing symmetrical visibility to both ends of the payment to accelerate coordinated response.

[0128] Some embodiments may provide a method for coordinated pre-execution, interinstitution early warning for digital payments, the method comprising: (a) receiving, from an originating institution, a pre-execution payment request containing payer session telemetry and recipient identifiers for evaluation; (b) concurrently inferring account-takeover likelihood and social-engineering risk for the payer using device lineage, behavioral baselines, and recent authentication outcomes; (c) querying a consortium coordinator to compute a recipient mule propensity score using recipient account maturity, inbound velocity, and session overlap indicators; (d) obtaining, within pre-defined latency thresholds, a combined risk decision aggregating payer and recipient signals with calibrated confidence measures and attributions; (e) propagating machine-readable indicators to the originating and receiving institutions forcoordinated step-up verification, just-in-time blocks, or post-execution containment; (f) recording immutable audit artifacts and idempotent event references enabling replay protection, cross-institution case linking, and model-risk governance evaluations across deployments.

[0129] Some embodiments may provide a method for bilateral actioning of standardized pre-payment risk signals across counterparties, the method comprising: (a) ingesting a contemplated payment’s amount, counterparty attributes, and channel context from a core banking platform prior to authorization execution; (b) generating parallel inferences for payer compromise and recipient mule behavior using temporal feature decay, graph features, and jurisdictional access controls; (c) evaluating policy thresholds configured by each institution against standardized Trust Risk Factors and Trust Data Points emitted by a network scoring service; (d) determining a coordinated action recommendation including hold, deny, step-up authentication, or proceed with monitoring, with rationales and human-readable explanations; (e) transmitting the recommendation and supporting indicators to counterparties over authenticated, encrypted channels with delivery acknowledgments and strict retry semantics; (f) persisting decision telemetry, outcome feedback, and performance statistics for continuous calibration, fairness monitoring, and alert-rate management across financial institutions.

[0130] In some embodiments, the system may provide privacy-preserving cross-bank matching that limits all exchanged identifiers to deterministic cryptographic digests and transports them only over authenticated and encrypted channels operated within approved cloud regions. The coordinator accepts payer and payee account numbers that have been transformed by a collision-resistant hashing function, such as SHA-256, optionally with institution-scoped or network salts, and rejects any payload containing raw names or other direct identifiers. At ingress, the platform verifies message integrity, normalizes to a canonical schema, and encrypts data at rest using institutionally approved standards, ensuring that even a worst-case disclosure yields only non-reversible digests with negligible reuse value to an attacker. Hashing semantics are one-way by construction, which prevents re-identification from the digest alone, while transport encryption restricts visibility in flight to mutually authenticated participants. These constraints allow compliant correlation of counterparties and payment flows across institutions without sharing personal data, thereby reducing data custody risk and simplifying legal review for multi-party deployments. The approach supports a federated trust network in which shared signals are strictly purposed for the prevention, detection, and investigation of fraud, scams, and related crime, and membership is bounded by jurisdiction unless expanded by mutual agreement. Documentation includes precise definitionsof hashing versus encryption, sample digest outputs for validation, and operational guardrails that prohibit expansion of scope outside allowed purposes.

[0131] Some embodiments may provide a method for privacy-preserving cross-bank correlation using hashed identifiers, the method comprising: (a) receiving hashed payer and payee account numbers produced by a collision-resistant function, excluding names and other direct personal identifiers; (b) validating message integrity, schema conformance, and participant authentication before accepting the payload into a privacy-preserving correlation workflow; (c) encrypting the digests at rest using institutionally approved algorithms and keys managed within an approved jurisdictional cloud region subject to regulatory requirements; (d) correlating counterparties across institutions by matching deterministic digests, thereby enabling cross-bank risk signals without disclosing underlying personally identifiable information; (e) restricting processing purpose to fraud, scam, and crime prevention, detection, and investigation through technical guardrails and contractual use-limitations controls; (f) producing audit logs demonstrating one-way hashing semantics, transport encryption, membership boundaries, and prohibition of scope expansion beyond permitted purposes.

[0132] Some embodiments may provide a method for compliant consortium data exchange with network-salted digest matching and jurisdictional controls, the method comprising: (a) transforming institution-specific identifiers into network-salted digests ensuring linkability across members while preventing external re-identification without institutional secret material; (b) rejecting any submission containing plaintext personal data, free-form names, or addresses by enforcing strict schema validation and inbound payload sanitization rules; (c) computing privacy budgets and data minimization metrics per participant to evidence compliance with applicable data protection and financial crime regulations; (d) distributing correlation outcomes and standardized risk indicators to authorized institutions via authenticated APIs implementing encryption, replay protection, and delivery acknowledgments; (e) enforcing jurisdictional residency by partitioning storage and compute to regional clusters with policy-based routing and immutable residency attestation artifacts; (f) generating compliance reports describing hashing methods, encryption controls, access paths, and processing purposes to support audits and regulator examinations across jurisdictions.

[0133] In some embodiments, the system may provide a calibrated Trust Scoring model that outputs a bounded integer score on a 0 to 1 ,000 scale together with standardized risk factors and data points consumable by bank rule managers and case tools. The model ingests crossinstitution features derived from sender session telemetry, device lineage, historical counterparty graphs, and receiver-provided account attributes, with temporal decay andjurisdictional gating applied to feature access. The scoring contract includes a fixed set of Trust Risk Factors and an extended set of Trust Data Points for configuration interfaces, enabling banks to write transparent policy thresholds, attach human-readable rationales, and maintain alert volumes comparable to incumbent ATO models while materially lifting detection on investment, impersonation, and business-email-compromise scam types. The platform supplies performance and alert-rate telemetry, versioned feature dictionaries, and confidence measures to support model-risk governance, and records tamper-evident audit events for each decision. Integration artifacts define synchronous APIs for pre-payment checks and asynchronous notifications for high-risk inbound payments, permitting both pre -execution interdiction and post-execution containment. The scoring model is designed for iterative improvement with clearly documented upgrade paths so institutions can validate new versions without disrupting downstream rules. By standardizing outputs and attributions, the system enables repeatable tuning across diverse core banking stacks and facilitates rapid policy iteration without requiring model retraining by each member.

[0134] Some embodiments may provide a method for standardized Trust scoring and decision attribution for electronic payments, the method comprising: (a) ingesting sender telemetry, device lineage, counterparty graph features, and receiver account attributes subject to temporal decay and jurisdictional gating policies; (b) computing a bounded integer Trust score on a 0 to 1,000 scale using calibrated models with versioned feature dictionaries and confidence measures; (c) emitting standardized Trust Risk Factors and Trust Data Points that attribute the decision to interpretable signals suitable for downstream rules and explanations; (d) evaluating institution-configured thresholds to produce recommended actions including decline, hold, step-up authentication, or proceed with monitoring and post-execution containment; (e) transmitting synchronous pre-payment decisions and asynchronous high-risk inbound notifications over idempotent APIs with replay protection and delivery confirmation semantics; (f) persisting performance telemetry, alert volumes, and outcome labels for continuous calibration, fairness monitoring, and model-risk governance across multiple financial institutions.

[0135] Some embodiments may provide a method for policy-driven integration of network Trust scores into core authorization workflows, the method comprising: (a) receiving a preauthorization inquiry from a core payment processor including transaction metadata, payer context, and candidate payee attributes for evaluation; (b) invoking a network scoring service that standardizes features, applies calibrated models, and generates a Trust score with aligned risk factor attributions; (c) mapping the Trust score and risk factors to institution-configuredpolicies that specify numerical thresholds, actions, notification recipients, and exception workflows; (d) executing the selected action path and furnishing human-readable rationales, confidence values, and supporting data points to operator consoles and case systems; (e) logging tamper-evident decision records, feature versions, and model identifiers to enable replay, comparability testing, and post-hoc regulatory examinations; (f) returning the decision outcome to the processor within service-level targets suitable for pre -execution holds and customer experience preservation across channels.

[0136] In some embodiments, the system may provide continuous mule detection that synthesizes recipient-side behavioral signals, device and session telemetry, and account lifecycle attributes to generate a recipient mule score and to notify counterparties when inbound risk exceeds configurable thresholds. The coordinator fuses device profiles, session overlap with victim activity, balance-checking cadence, inflow velocity, and app usage indicators observed near payment events, and combines these with maturity attributes of the recipient account, such as account age and time-since-first-seen as payee or payer, to detect mule infrastructure that often appears benign in single-bank views. High-risk recipients trigger early alerts to the receiving bank for containment, and step-up or decline actions at the sender, with both processed and declined attempts recorded to accelerate case linking. Empirical network insights indicate that a substantial fraction of fraud and scam payments route to accounts exhibiting elevated mule scores, which can be mined as a preemptive interdiction signal. The methodology pairs naturally with sender-side ATO and scam indicators to expose two-sided patterns for nuanced typologies, including investment and impersonation scams. Operationally, the system streams notifications and structured risk factors over API and file channels that integrate into existing fraud platforms, while preserving zero impact to genuine users through precise thresholds and policy tuning guided by standardized data points. This construction delivers rapid, coordinated response on both ends of the payment and increases recovery probability when funds movement cannot be stopped.

[0137] Some embodiments may provide a method for continuous recipient mule detection and two-sided scam interdiction, the method comprising: (a) collecting recipient-side telemetry including device fingerprints, session overlaps with victims, balance-check cadence, inbound payment velocity, and application interaction patterns; (b) computing a recipient mule score using calibrated models that weight account maturity, first-seen timestamps, and anomalous behavioral sequences surrounding payment events; (c) correlating high-scoring recipients across institutions to identify mule infrastructure, reuse patterns, and clusters facilitating fraud and scam payment routing; (d) notifying the receiving institution upon detection of high-riskinbound payments and providing structured indicators suitable for rapid containment and recovery workflows; (e) transmitting sender-side scam and account-takeover indicators to the originating institution to support step-up verification, declines, or customer education interventions; (f) storing processed and declined event references to accelerate cross-case linking, restitution attempts, and intelligence feedback loops improving future interdiction effectiveness.

[0138] Some embodiments may provide a method for networked mule risk classification with feedback-driven model governance, the method comprising: (a) receiving inbound payment notifications from network participants including hashed recipient identifiers, transaction descriptors, and time-bounded session context for analysis; (b) deriving behavioral features describing account lifecycle, counterparty diversity, device reuse, and balance interrogation frequency across rolling temporal windows; (c) assigning a mule risk classification with calibrated confidence and reason codes, then publishing standardized factors suitable for policy tuning and operator interpretation; (d) dispatching alerts to receiving institutions for containment actions and to originating institutions for pre-execution step-up or cancellation opportunities; (e) integrating outcomes, recovery results, and operator feedback to retrain models under governance controls with rollback, champion-challenger testing, and fairness checkpoints; (f) maintaining customer experience protections by applying thresholds minimizing false positives and suppressing repeated alerts through idempotent references and deduplication logic.

[0139] Reference is made to Fig. 1, which is a schematic block-diagram illustration of a System 100, in accordance with some demonstrative embodiments. System 100 may be implemented by utilizing suitable hardware components and / or software components. Some of the following components may be optional, and need not necessarily be included in some implementations .

[0140] Bank-Side Behavioral Analysis Unit 101 derives behavior vectors for the first party based on signals that the first bank can lawfully observe. Inputs include recent session telemetry, device posture, payment cadence, geo-temporal consistency, and channel provenance for the inspected transaction. The unit transforms raw traces into normalized features using robust scaling and outlier clipping to resist single-feature manipulation. It maintains a rolling baseline with decay to emphasize recent conduct while retaining enough history for seasonal patterns. A contrastive encoder projects the baseline and current snapshot into the same space, and a distance kernel measures deviation along axes that matter for fraud typologies such as account takeover or mule behavior. The output is a behavior divergencescore with explanations indicating which sub-patterns contributed most. The unit also tags features as sensitive or non-sensitive and redacts the former before any cross-institution exchange. For resiliency, it detects drift in upstream telemetry and auto-relearns scaling parameters within bank boundaries. All computations occur within the bank’s controlled environment, and only a compact, bank-local behavior signature is exposed to other components. The signature can be regenerated deterministically for audit, eliminating the need to store long-lived behavioral raw data.

[0141] Bank-Side Fraud Signals Detector 102 aggregates discrete fraud indicators that the first bank already computes for operational risk. Inputs include device reputation classifications, velocity limits, prior dispute linkages, AML alert echoes, and step-up authentication outcomes tied to the inspected transaction. The detector removes duplicative evidence by mapping indicators onto a canonical taxonomy and then applies learned weights that reflect historical predictive utility for cross-institution risk. A gating function suppresses indicators with poor calibration in the current segment, which reduces false contribution from stale models. Outputs include a sparse vector of normalized fraud signals, each annotated with confidence and freshness. The detector also generates a hashed evidence ledger where each indicator is salted, hashed, and bound to a time nonce, enabling later reconciliation across banks without revealing the underlying account identifiers. For security, signatures are sealed in a hardware-backed enclave and exported only as signed tokens that downstream modules can verify. The module supports counterfactual probing, emitting an alternate vector that simulates the effect of one missing indicator to help later components assess sensitivity. All exports are strictly bank-scoped and do not contain personal data fields, aligning with the invention’s privacy-preserving exchange model.

[0142] Bank-Side Transactions Analyzer 103 focuses on the inspected transaction’s structural attributes as seen by the first bank. Inputs include payment rails metadata, transfer purpose codes, beneficiary category labels, instrument type, currency paths, and channel friction metrics. The analyzer builds a transaction fingerprint that captures structural shape rather than identity. It uses grammar-based parsing to segment the payment into motifs such as “first-time external payee with exceeded typical amount” or “repeated micro-transfers with widening intervals.” A probabilistic rules engine scores motifs according to learned risk lift from the bank’s historical outcomes. The analyzer also estimates plausible counterparty profiles from payee attributes that are visible to the first bank, while keeping those attributes confined to the bank. Outputs include a structural risk vector, motif inventory, and an encrypted hint field that helps the cross-bank correlator align structural views across institutions withoutsharing sensitive payloads. The module is designed to be robust against adversarial splitting or merging of payments by normalizing across partials and batched items. It emits a calibration packet that allows downstream cross-institution scoring to adjust for the bank’s specific rail mix and sampling bias.

[0143] Bank-Side Hashing Unit 104 converts sensitive identifiers that the first bank holds into hashed values for privacy-preserving correlation. Inputs include account numbers, device IDs, and payee reference numbers where lawful and necessary. The unit applies keyed hashing with per-context salts that rotate on a defined schedule. It supports blinded evaluation through commutative hashing, enabling two banks to match on equality without disclosing the preimage or the salt. For linkability control, the unit issues different salts for different use contexts so that a hash in one scoring workflow cannot be trivially joined to another. It also embeds a version tag and algorithm identifier into the exported token, which allows downstream components to refuse mismatched or obsolete formats. Outputs are nonreversible hashed tokens and zero-knowledge proof stubs that assert correct construction without revealing inputs. The unit has a misuse guard that rejects requests to hash fields not on an allowlist. It records a hash-of-hashes audit chain for later dispute resolution while never storing the source identifiers. The design ensures the system can detect that two banks refer to the same transaction or party using only hashed values, aligning with the invention’s cross-institution privacy goals.

[0144] Second Bank’s Detector / Analyzer / Hashing 105 is shown a single element, representing units of the second bank that correspond to units 101 to 104 of the first bank, and that operate on signals and data that the second bank collects or monitors; such as, second bank’s behavioral analysis unit for monitoring and analyzing the behavior of the second user (e.g., the payee in the transaction), second bank’s fraud signals detector, second bank’s transaction analyzer, and second bank’s hashing unit. Those components operate inside or by or on behalf of the second bank; and they produce its own behavior signature for the second party or for the transaction as observed on that side. Inputs mirror the second bank’s telemetry footprint, which may differ from the first bank’s. These units (105) align feature distributions locally using bank-specific calibrations and emits a signature in a shared embedding space defined by a published schema but trained on bank-local data. A reconciliation routine estimates embedding comparability by validating that anchor behaviors land in similar regions across time. When anchors drift, the unit re-centers its projection while keeping prior signatures reproducible through stored transformation digests, not raw data. Outputs include a behavior divergence score, saliency markers, and a set of hashed anchors that permit the cross-bankcorrelator to check that both sides refer to the same payment episode. In some embodiments, the units (105) of the second bank deliberately suppress or anonymize or conceal or replace or hide or discard or hash any attributes that could reveal the second party’s identity when exported. It also supports temporal slicing, producing separate signatures for pre-initiation, authorization, and settlement windows, enabling downstream modules to reason about stagespecific anomalies without violating data minimization.

[0145] Combined Inter-Institutional Fraud-Relatedness Score Generator 106 produces the fraud-relatedness score for the inspected transaction by fusing the two banks’ exports without centralizing raw data. Inputs include the behavior signatures from unit 101 and unit 105, the fraud signals vectors from unit 102 and its second-bank analog, and / or the structural fingerprints from unit 103 and its counterpart. In some embodiments, the Generator 106 operates at a trusted third-party server that is external to the first bank and the second bank; in other embodiments, Generator 106 may be implemented in or by one of the two banks, or in both of the banks, such as by following an operational flow in which Bank A sends directly to Bank B the fraud-related signals that Bank A found such that the Generator at Bank B can generate the combined inter-institutional fraud-relatedness score by taking those into account together with the fraud signals that Bank B itself collected or detected; or conversely, by following an operational flow in which Bank B sends directly to Bank A the fraud-related signals that Bank B found such that the Generator at Bank A can generate the combined inter-institutional fraud-relatedness score by taking those into account together with the fraud signals that Bank A itself collected or detected. In this example, Bank A can be the payer bank, and Bank B can be the payee bank; or vice versa.

[0146] The generator 106 operates in a secure compute zone that accepts only signed, hashed, and schema-validated packets. It uses a cross-domain attention model that highlights concordant anomalies, such as a payee behavior spike on one side aligned with sender friction on the other. A causality-aware layer discounts patterns that are likely artifacts of rail differences or cutoff times. The generator computes a scalar fraud-relatedness score with calibrated uncertainty, and emits reason codes bound to feature clusters rather than raw fields. It produces variant scores under different privacy budgets to allow downstream policy to choose strict or permissive thresholds. The module never reconstructs personal identifiers; it works solely with hashed tokens and derived embeddings. For audit, it emits a cryptographic receipt that proves which inputs contributed and which were ignored due to policy or integrity failures, enabling defensible, cross-institution decisions.

[0147] Cross-Bank / Cross-Institution Correlator 107 (which may be part of the trusted third-party server, or may be part of the Bank A system or part of the Bank B system) aligns exports from multiple institutions that relate to the same transaction or to dependent events. Inputs are hashed tokens for payer and payee references, transaction fingerprints, time windows, and optional rail anchors. The correlator employs private set intersection methods to find overlapping hashed values without revealing non- matches. For cases with no direct hashed equality, it uses locality-sensitive hashing over structural fingerprints to detect probabilistic matches that still respect privacy constraints. The module assigns a correlation confidence and explains whether the linkage came from exact token equality, time adjacency plus structural similarity, or validated anchor pairs. Outputs are correlation bundles that group per-bank artifacts into a single episode object for downstream scoring. The correlator includes replay resistance by tracking seen tokens in a rolling Bloom filter and refusing suspicious duplicates. It also detects splitting strategies where adversaries move value through intermediate accounts across banks by linking sequences of small correlated transfers into a composite pathway. All correlation evidence is exported as blinded proofs that allow each bank to verify that no nonauthorized fields were used to establish the link.

[0148] Privacy-Preserving Feature Alignment Unit 108 harmonizes feature spaces across banks without exposing raw fields. Inputs include per-bank feature schemas, embedding specs, and calibration digests. The orchestrator negotiates a joint latent space by publishing a public alignment map derived from federated averaging on synthetic anchors that contain no personal data. Banks train local encoders to map internal features to this latent space and provide signed alignment residuals that quantify fit. The orchestrator monitors residual drift and triggers alignment refresh cycles while ensuring older exports remain decodable through versioned adapters. Outputs include alignment certificates that downstream models can trust, along with small adapter matrices that allow backward compatibility when one bank upgrades its encoders. The orchestrator also computes privacy budgets for different feature families and enforces per-family exposure caps, preventing excessive leakage from any single domain. Its innovation lies in achieving useful cross-institution comparability using only public anchors, residual statistics, and cryptographic attestations, never centralized feature data.

[0149] Adversarial Pattern Sanitizer and Robustness Unit 109 defends the pipeline against crafted inputs designed to evade cross-bank scoring. Inputs are bank-exported vectors, signatures, and tokens. The sanitizer tests these inputs against a library of adversarial perturbations learned from red-team exercises, including low-amplitude timing shifts, fake device churn, and motif camouflage that imitates benign payroll. A robust aggregation layerapplies median-of-means and trimmed estimators to reduce the influence of outliers. The module flags inputs that require excessive correction, which can indicate manipulation, and downgrades their weight in the final score. It also runs conformance checks against schema invariants to catch malformed or deliberately ambiguous exports. Outputs are sanitized vectors, a robustness score, and recommended penalties for use by the score generator. The sanitizer maintains explainability by recording which defenses were activated and how much each altered the input. All processing occurs on derived data, and the original hashed tokens are passed through unchanged to preserve correlation integrity.

[0150] Temporal Anomaly Sequencer 110 constructs time-ordered narratives from scattered bank exports. Inputs include timestamped behavior signatures, structural fingerprints across transaction stages, and correlation bundles from unit 107. The module constructs event sequences with monotonicity constraints and inserts inferred states where one bank’s view has gaps. It then applies sequence kernels that detect abnormal orderings such as reversal attempts, pre-authorization device switching, or synchronized micro-payments mapped to later aggregation. A dynamic time warping routine aligns sequences from both banks even when their clocks are skewed, using anchor events to correct offsets. Outputs include a temporal risk contribution that captures not just magnitude of anomalies but their order and proximity. The sequencer also produces counterfactual timelines that show what the score would be if certain steps had not occurred, supporting adjudication and appeal without revealing personal data. Sequence artifacts are emitted as hashed step IDs with relative ordering, enabling downstream explanation without exposing absolute times.

[0151] Counterparty Graph Embedding Synthesizer 111 embeds parties and instruments into a privacy-preserving graph space. Inputs are hashed tokens for parties and accounts, relationship hints such as shared devices or addresses encoded as salted hashes, and edge types like “co-occurrence within settlement batch.” The synthesizer constructs a local graph per bank and computes node embeddings with differential privacy noise calibrated to preserve community structure while protecting individual edges. It then applies a secure aggregation protocol to combine embedding centroids across banks without exposing any local graph. Outputs include cross-institution community proximity scores that indicate whether the inspected transaction bridges distant regions or reinforces known mule corridors. The module can flag anomalous triads where the sender and receiver rarely meet except through a newly formed high-risk intermediary. Embedding exports are versioned and accompanied by privacy loss accounting so that downstream components can respect exposure budgets. No raw neighbor lists are shared, only noisy vector representations and proofs of privacy parameters.

[0152] Zero-Knowledge Policy Attestation Engine 112 proves to counterparties that each bank followed required local policies when producing exports, without revealing policy internals. Inputs are policy templates, execution traces for units 101-105 at each bank, and signed configuration digests. The engine constructs non-interactive zero-knowledge proofs that certify, for example, that sensitive fields were hashed with approved algorithms, that retention windows were respected, and that blacklisted features were excluded. Outputs are succinct attestations attached to exported packets. Downstream modules verify these proofs before accepting data, refusing contributions that fail attestation. The engine also supports selective disclosure, allowing a regulator to validate stricter conditions using different verification keys while ordinary counterparties see only the minimal proof set. This mechanism raises trust among institutions while preserving competitive confidentiality and customer privacy.

[0153] Causal Influence Estimator for Multi-Bank Signals 113 separates correlation from causation in the fused risk picture. Inputs are sanitized vectors, temporal sequences, and graph proximity scores. The module builds structural causal models that encode plausible pathways, such as device compromise leading to abnormal behavior leading to out-of-policy transfer. It estimates intervention effects by simulating do-operations on specific features and measuring score sensitivity. The estimator discounts signals that are likely downstream of benign causes, like payroll schedule shifts, and elevates signals that maintain influence under multiple plausible worlds. Outputs are causal contribution weights and uncertainty intervals. These weights inform the final fraud-relatedness score so that it reflects likely causes rather than merely co-occurring anomalies. The estimator exports a compact causal card that records tested interventions without exposing any private attributes.

[0154] Risk-Aware Threshold Personalizer 114 converts the scalar fraud-relatedness score into an actionable decision while respecting each bank’s risk tolerance and legal constraints. Inputs include the combined score, uncertainty, reason codes, and bank-specific policy profiles. The personalizer computes dynamic thresholds per corridor, amount, and customer segment, and it applies asymmetric loss to reflect that false positives and false negatives carry different costs. It supports pre-decision holds that request additional, privacy-preserving evidence rather than blocking outright, such as a fresh hashed device proof. Outputs are decision recommendations with dwell time budgets and fallback paths if a counterparty cannot respond in time. The personalizer also tracks fairness metrics across segments using only aggregate, non-identifying statistics and triggers policy review when disparities exceed limits. All exported decisions carry a machine-verifiable rationale, mapping from score and policy to action.

[0155] Encrypted Evidence Binder and Receipt Issuer 115 packages all inputs and intermediate artifacts into a tamper-evident bundle for audit. Inputs are the signed packets, proofs, and reason codes produced across modules. The binder constructs a Merkle tree over artifacts, stores leaves in bank custody, and exports only the root and a minimal set of inclusion proofs. It issues a cryptographic receipt that each bank and any designated overseer can verify independently. The binder supports selective unsealing, where a dispute process can reveal just enough to validate a decision without exposing unrelated data. It also tracks data provenance across institutions, preventing circular evidence reuse in later cases. Outputs are receipt tokens attached to the decision record and short-lived verification URLs that resolve to proof material under strict access control. No personal identifiers are present, only hashes and signatures.

[0156] Differential-Privacy Budget Governing Unit 116 measures how much information about any party can be inferred from repeated cross-bank exchanges. Inputs are logs of exports with their reported privacy parameters and the number of times a hashed token appeared in correlation bundles. The governor composes privacy loss using standard accounting, then enforces hard caps by instructing upstream modules to degrade precision or stop exporting certain feature families for overexposed tokens. Outputs include updated privacy budgets and compliance flags attached to each packet. If a token approaches exhaustion, the governor recommends alternative evidence types with lower privacy cost, such as structural motifs rather than behavior vectors. The governor’s records are themselves privacy-protected and can be audited through zero-knowledge summaries that show compliance without revealing the subjects of the budgets.

[0157] Execution Manager Unit 117 coordinates hardware-backed execution of sensitive fusion steps. Inputs are code measurements, keys, and policy rules specifying which modules require enclave protection. The manager provisions enclaves, attests to their integrity to counterparties, and seals keys for the duration of a computation. It also orchestrates sidechannel mitigations such as constant-time operations for hashing and noise injection for timing. Outputs are attestation quotes attached to results, allowing banks to verify that, for example, the combined score in unit 106 was computed inside a trusted environment with the expected binary. The manager rotates enclaves and keys on a schedule to limit exposure, and it records enclave lifecycles in the evidence binder. It exposes only minimal telemetry about enclave health and never the data processed within.

[0158] Model Governance and Drift Detector 118 oversees models used in behavior encoding, motif scoring, and cross-domain attention. Inputs are version manifests, calibration metrics, outcome feedback from post-decision events, and privacy budget states. The sentineldetects drift in data distributions across banks and flags when a model’s calibration falls outside tolerance for certain corridors or amounts. It can issue a controlled rollback to a prior model version while keeping alignment adapters valid, ensuring cross-bank comparability. Outputs include governance attestations that bind model version, training window, and compliance checks to each score. The sentinel also runs counter-abuse tests to make sure that model updates cannot be exploited to de-weight critical signals. It publishes a compact, signed governance card with every decision artifact, enabling later reviewers to reconstruct exactly which statistical objects produced the outcome, without access to any raw personal data.

[0159] Federated Evidence Fusion Controller 119 governs and / or controls and / or manages the distributed assembly of fraud evidence across participating institutions without central data pooling. Inputs include pre-sanitized vectors, hashed tokens, and zero-knowledge attestations from each bank’s internal modules. The controller can establish a secure multiparty computation (MPC) session where encrypted feature fragments are combined into joint tensors, allowing statistical inference without revealing individual contributions. It uses homomorphic encryption for additive operations and secret sharing for nonlinear layers, automatically selecting computation methods that minimize latency under bandwidth constraints. A session orchestrator maintains ephemeral keys and enforces strict disposal after aggregation completion. Outputs include aggregated gradient estimates for updating shared models and fused statistical summaries such as joint anomaly density functions. The component’s innovative element lies in its adaptive encryption pipeline: it dynamically changes cryptographic schemes depending on data entropy and institutional trust tiers, maintaining privacy guarantees while ensuring usable performance in real-time fraud detection environments.

[0160] Cross-Domain Token Integrity Verifier 120 ensures that all exchanged tokens (e.g., hashed identifiers, correlation stubs, or proof referencesO are authentic and unaltered during transit. It receives as input the signed token bundles produced by multiple banks, each accompanied by digital signatures and timestamp proofs. Using chained certificates rooted in a consortium-managed authority, the verifier validates signature correctness, expiry status, and issuance context. It employs probabilistic verification using Merkle proof sampling for efficiency while guaranteeing bounded verification error. The module also identifies misuse patterns, such as token replay or multi-context use beyond its allowed scope. Once verified, it emits integrity badges and freshness scores embedded within the inter-bank data stream. Downstream analytics trust only data carrying verified badges. The verifier’s innovation stems from its probabilistic integrity checking model, which maintains cryptographic rigor whilescaling linearly with token volume; an important feature for high-frequency transaction networks processing millions of entries per minute.

[0161] Adaptive Model Parameter Synchronizer 121 maintains coherence between local fraud-detection models operating at each institution while respecting jurisdictional data barriers. Inputs include encrypted model weight deltas, privacy budgets from unit 116, and governance cards from unit 118. Using federated averaging with adaptive clipping, it reconciles divergent weight updates into a global reference vector, mitigating bias caused by unbalanced data volumes across banks. It periodically recalibrates feature normalization statistics using publicly available anchor distributions to prevent silent model drift. Outputs are new model checkpoints signed by the Model Governance unit, alongside metadata describing each institution’s relative contribution to the update. A key innovation lies in the synchronizer’s “differential learning window” algorithm, which suppresses weight adjustments derived from overexposed or privacy-exhausted tokens, ensuring that learning remains both compliant and representative. By maintaining consistent global intelligence without ever aggregating personal data, this component enables the entire system to learn from fraud patterns observed across the financial ecosystem.

[0162] Inter-Bank Encryption Key Rotator 122 automates lifecycle management of encryption keys used in secure exchanges among participating banks. Inputs are key rotation schedules, certificate validity intervals, and evidence logs of prior exchanges. The rotator executes cryptographic key generation inside hardware security modules (HSMs) at each institution, coordinates public key exchanges through the Secure Enclave Manager 117, and updates distributed ledgers with new key fingerprints. It maintains backward compatibility by supporting overlapping validity windows, allowing in-flight computations to finish without interruption. Outputs include signed rotation manifests and revocation proofs propagated to all peers. Its innovative aspect lies in its “rotational continuity assurance” logic, which detects and remediates synchronization lag between institutions by issuing temporary dual-signing tokens that allow interoperability until all parties confirm the rotation. The result is a cryptographically agile ecosystem where key management occurs transparently, securely, and without operational downtime.

[0163] Secure Multiparty Proof Verifier 123 validates that complex multiparty computations have adhered to agreed-upon protocols without inspecting any participant’s private inputs. Inputs include non-interactive zero-knowledge proofs (NIZKs) generated during fraud-score aggregation and model synchronization processes. The verifier performs layered proof validation: it checks consistency between declared operations and hash commitmentsfrom each participant’s enclave logs, ensures no omitted participants, and verifies homomorphic encryption parameters. Outputs are attested proof bundles containing verification outcomes and concise failure reports, if any. The innovative contribution is its “hierarchical proof collapsing” scheme, which compresses large chains of individual NIZKs into a single succinct proof with constant-size verification cost. This drastically reduces verification overhead while maintaining cryptographic integrity, enabling scalable, verifiable cooperation across dozens of institutions engaged in concurrent fraud detection.

[0164] Behavioral Signature Canonical Format Converter 124 operates to harmonize heterogeneous behavioral signatures produced by different banks so they can be meaningfully compared. Inputs are the raw behavior embeddings from modules 101 and 105, plus alignment certificates from 108. It performs orientation normalization using cosine similarity alignment, removes redundant axes via principal manifold projection, and scales magnitudes using adaptive variance equalization. The canonicalized signature becomes a standardized vector representation residing in a shared latent space, ensuring consistent interpretation by the Combined Score Generator 106. Outputs include transformed embeddings and alignment drift indicators. The innovation lies in its “context-aware manifold reparameterization,” which detects when a behavior dimension correlates differently across banks and dynamically remaps that axis, preventing cross-bank misinterpretation of identical numeric values. This ensures robust comparability even when individual institutions evolve their internal behavior models independently.

[0165] Hashed Transaction Topology Mapper 125 reconstructs an abstract topological view of transactions from multiple banks while preserving full anonymity. Inputs are hashed transaction identifiers, timing intervals, and linkage evidence from the Cross-Institution Correlator 107. Using these, the mapper builds a dynamic directed graph representing transaction flows across institutions, where nodes are anonymized entities and edges represent verified value movements. It applies spectral clustering to detect subnetworks exhibiting cyclic or high-degree connectivity typical of laundering rings. Outputs include anonymized topology descriptors and risk elevation indices for each subnetwork. The mapper’s novelty lies in its “hash-preserving isomorphism” algorithm that allows identical network structures to be recognized across banks even when each node uses different salted hashes, thereby enabling collaborative topological analysis without ever revealing true account relationships.

[0166] Semantic Transaction Context Inference Engine 126 enriches the analytical pipeline by inferring semantic intent behind transactions using metadata and contextual embeddings. Inputs include payment descriptions, channel metadata, and behavioral context from units 101—105. Using a large-domain transformer trained under federated conditions, it maps tokens and transaction labels to semantic categories such as payroll, refund, or peer-to-peer transfer, expressed as privacy-safe numerical embeddings. Outputs are contextual meaning vectors with confidence scores. The innovation lies in the “semantic abstraction without reconstruction” framework: rather than recovering plaintext, it derives meaning through differential cooccurrence embeddings that never reconstruct the actual words. This allows the system to incorporate linguistic or categorical context while fully preserving data confidentiality, dramatically enhancing the interpretability and precision of fraud-relatedness scoring.

[0167] Cross-Consortium Audit Trail Ledger 127 serves as a distributed, append-only record of all inter-bank interactions relevant to fraud-scoring operations. Inputs are event receipts, proof hashes, and transaction identifiers in anonymized form. Built atop a fault-tolerant consensus protocol, the ledger records attestations, key rotations, and model updates, ensuring that any participant can verify chronological integrity. It supports selective disclosure through cryptographically masked transaction groups visible only to authorized auditors. Outputs include verifiable audit queries that can confirm the provenance and authenticity of any fraud decision. The innovative feature is its dual-mode transparency architecture: a public metadata layer that logs system operations and a private evidence layer accessible only through threshold decryption, enabling regulators to audit effectively while safeguarding bank-level confidentiality.

[0168] Explainable Decision Reconstruction Console 128 provides authorized analysts with interpretable reconstructions of the reasoning behind each fraud-relatedness score. Inputs include the decision artifacts, causal weights from unit 113, and reason codes from unit 106. The console uses counterfactual simulation to show how altering particular features would have changed the score, while maintaining compliance through differential privacy on simulated data. Outputs are visual and textual summaries, audit logs, and evidence linkage graphs. Its novel element is the “federated explainability fabric,” which allows cross-bank transparency without exposing underlying private data, achieved by reconstructing explanations from aggregated causal primitives rather than raw features. This component significantly enhances trust and regulatory defensibility of automated fraud determinations.

[0169] Synthetic Risk Scenario Generator 129 creates realistic, privacy-preserving synthetic datasets that replicate risk phenomena observed in production systems. Inputs include abstracted statistics, motif patterns, and anonymized embeddings from modules 101-107. It employs generative adversarial modeling within a federated environment, where each bank trains a local generator that contributes gradient updates to a global model without sharing data.Outputs include synthetic event streams used for stress-testing fraud models and validating robustness against rare or emergent attack vectors. Its innovation lies in the “bounded realism discriminator,” which ensures that synthetic outputs remain statistically faithful to global distributions while provably untraceable to any real individual or transaction, balancing realism and privacy in a measurable way.

[0170] Contextual Trust Weight Calibrator 130 adjusts confidence levels assigned to each institution’s input data based on context and reliability metrics. Inputs are integrity badges from unit 120, model drift data from unit 118, and historical validation scores. Using Bayesian evidence accumulation, it computes posterior trust weights that scale contributions to the final score. It penalizes data from institutions exhibiting high drift, poor proof freshness, or inconsistent schema adherence. Outputs include per-bank trust multipliers and aggregated uncertainty budgets. The innovation is its “contextual credibility lattice,” a dynamic probabilistic structure that models inter-institution reliability dependencies rather than treating each bank independently. This ensures that collective scoring remains stable even when some participants experience temporary data quality degradation.

[0171] Regulatory Compliance Interpreter 131 dynamically enforces region-specific regulatory constraints during processing. Inputs are jurisdiction codes, transaction corridors, and data exposure classifications. It references a machine -readable rulebook encoded in policy graphs that specify permissible operations under each legal framework. During runtime, the interpreter intercepts data flows and applies necessary transformations, such as differential noise scaling, data residency routing, or feature suppression. Outputs include compliance execution logs and modified data packets with embedded jurisdiction tags. Its innovation lies in the “live regulatory compiler,” which converts new legal updates published in structured form into executable policy modules automatically, ensuring that the system continuously complies without manual intervention across multi-country deployments.

[0172] Entropy-Based Anomaly Amplifier 132 enhances sensitivity to low-frequency, high-impact anomalies that may be diluted in aggregate statistics. Inputs are intermediate risk distributions, sequence residuals, and graph embeddings. It computes entropy gradients across these distributions to identify patterns that diverge from typical variability. When detected, it amplifies their influence on the final score through controlled scaling functions that preserve calibration. Outputs include entropy-adjusted anomaly signals and explanatory metrics describing their origin. The innovative contribution is its “entropy-adaptive gain control,” which ensures that the amplifier strengthens only statistically significant rare patterns, avoidingnoise inflation. This allows the system to surface stealthy, sophisticated fraud patterns without overwhelming analysts with false positives.

[0173] Cryptography Layer 133 includes encoder / s and / or decoder / s and / or encryption unit / s and / or decryption unit / s and / or digital signature unit / s and / or digital hashing unit / s and / or digital salting units, and can optionally future -proof the platform’s cryptographic foundations against quantum computing threats. Inputs include all encryption, signing, and hashing operations performed by upstream modules. The layer can transparently substitute traditional RS A or ECC primitives with lattice-based and hash-based algorithms (e.g., Kyber and Dilithium), depending on operation type. It ensures backward compatibility by encapsulating classical and quantum-safe keys within hybrid certificates. Outputs include post-quantum secure message envelopes and cryptographic audit records. The innovative feature is its “hybrid agility controller,” which dynamically negotiates the strongest mutually supported cipher suite among participants, enabling gradual migration to quantum-safe protocols without downtime or incompatibility, thereby extending the system’s long-term viability.

[0174] Federated Differential Auditing Unit 134 performs privacy-compliant auditing of model and system performance across institutions. Inputs include aggregated, anonymized performance metrics, differential-privacy noise parameters, and model governance records. It runs multi-party statistical tests to assess bias, calibration, and fairness while guaranteeing each institution’s metrics remain confidential. Outputs include audit summaries with formal privacy guarantees, suitable for regulators and consortium oversight. Its innovative mechanism, “statistical indistinguishability sampling,” ensures audit results remain stable despite noise injection, providing trustworthy cross-bank accountability without exposing sensitive datasets.

[0175] Dynamic Data Provenance Tracker 135 maintains lineage records for every data element that contributes to a decision. Inputs are metadata from modules 101 through 133, including timestamps, hash chains, and transformation digests. It reconstructs the complete derivation path for each feature (e.g., where it originated, how it was transformed, and which computations consumed it) represented as a directed acyclic provenance graph. Outputs include signed lineage maps and integrity checksums that regulators can verify independently. The innovative element lies in its “privacy-preserving lineage compaction,” which summarizes transformations cryptographically rather than verbosely, achieving full traceability with minimal data exposure.

[0176] Anonymized Model Feedback Integrator 136 processes post-decision outcomes from banks (confirmed frauds or false alarms) in a privacy-safe way. Inputs include outcome tags attached to anonymized transaction references and corresponding model predictionsignatures. It applies federated expectation-maximization to update probability calibration functions without ever joining outcomes to identifiable entities. Outputs are updated reliability curves and calibration offsets distributed back to each institution. Its novelty lies in the “splitfeedback coupling” method, where feedback influence is divided between structural motifs and behavioral features, ensuring that each signal improves the right sub-model without creating data leakage paths.

[0177] Cross-Institution Latency Optimizer 137 minimizes response times in multi-bank computations. Inputs include network telemetry, message queue lengths, and enclave execution durations. It models latency as a stochastic process and employs adaptive batching plus parallel proof verification to reduce end-to-end delay. The optimizer can prefetch probable correlations based on recent transaction history, overlapping computation with communication. Outputs include latency-adjusted scheduling plans and performance reports. Its innovative “anticipatory synchronization” technique predicts cross-bank handshake timing using historical distributions, allowing near-real-time fraud scoring even under network heterogeneity.

[0178] Cumulative Trust Ledger Consolidator 138 accumulates trust evidence over time for each institution and network segment. Inputs are periodic trust multipliers from 130 and proof verifications from 120. It updates a time-decayed ledger that records each participant’s reliability trajectory. Outputs include consolidated trust ratings and deviation alerts when a bank’s behavior deviates from its historical trust profile. Its novelty is the “forensic decay kernel,” which decays trust non-linearly depending on deviation severity, enabling faster recovery from minor issues while imposing longer penalties for severe integrity violations. This mechanism enforces self-correcting behavior across consortium participants.

[0179] Privacy-Adaptive Communication Bus 139 is an interconnect or pipeline that handles encrypted message routing between components across institutions. Inputs are serialized data packets with privacy labels and routing intents. The bus enforces label-aware routing: sensitive packets travel only through certified privacy zones, while public metadata uses standard channels. It supports multiplexed channels where encryption algorithms are dynamically chosen per packet type. Outputs include transmission confirmations and privacy compliance metrics. Its innovation lies in “adaptive envelope synthesis,” which wraps each message in a cryptographic container optimized for its confidentiality class, reducing computational overhead while guaranteeing compliance with the most stringent data protection requirements.

[0180] Forensic Simulation Reconstructor 140 reconstructs hypothetical fraud scenarios for investigative and training purposes. Inputs include anonymized decision records, behavioralembeddings, and topology maps. Using constraint-based simulation, it replays sequences of events to show how coordinated fraud might propagate across banks. The simulator applies stochastic perturbations to test system robustness and generate counterfactual scenarios. Outputs include forensic timelines and synthetic training data labeled with causal explanations. Its innovative feature is the “temporal reverse inference engine,” which can infer plausible earlier states from later evidence, helping investigators understand undetected precursors to complex fraud events without needing to expose real transaction details.

[0181] Anomaly Consensus Resolver 141 mediates differences when institutions’ local assessments disagree on the fraud-relatedness of the same transaction. Inputs include per-bank scores, uncertainty intervals, and trust weights from unit 130. It applies multi-agent consensus algorithms based on weighted median aggregation, enhanced by conflict-resolution heuristics that consider each participant’s reliability history. If disagreement exceeds thresholds, it triggers a federated adjudication protocol where additional encrypted evidence is exchanged until convergence. Outputs include consensus scores and resolution proofs. The innovation is its “trust-weighted contradiction attenuation,” which dampens extreme outliers proportionally to participant credibility, yielding stable and equitable cross-institution decisions.

[0182] Interpretable Risk Ontology Manager 142 may optionally maintain and / or update the hierarchical taxonomy of fraud concepts and risk indicators used throughout the system. Inputs include new pattern discoveries from unit 119, semantic embeddings from unit 126, and regulatory updates from unit 131. It organizes these into an ontology graph connecting behavioral, structural, and contextual risk concepts. The manager ensures that all system components reference a consistent vocabulary of risk semantics, mapping low-level features to human-understandable categories. Outputs include ontology updates, version control records, and semantic alignment adapters for downstream visualization tools. Its innovative element is the “self-evolving ontology compiler,” which automatically integrates emerging fraud patterns by abstracting common substructures across models, enabling the system to evolve its conceptual understanding of fraud continuously without manual curation.

[0183] Fraud Mitigation Unit 143 triggers or launches or commands or executes one or more fraud mitigation or fraud remediation operations, based on pre-defined rules or escalation rules or severity rules; if the combined inter-institutional fraud-relatedness score is above a threshold level, or is within a particular threshold range of values. Such mitigation operations may include, for example: rejecting or denying or stopping the submitted transaction; canceling or discarding the submitted transaction, or preventing its execution; pausing or delaying or quarantining the transaction execution for further investigation; requiring the first party and / orthe second party to perform additional step(s) of user authentication (e.g., to receive and to enter a one-time code via a trusted device; to click on a link in a trusted application in a trusted device; to call customer service by phone for further investigation and authentication); to send one or more messages to pre-defined parties (e.g., fraud department; loss prevention department; law enforcement; money laundering prevention authority; terror funding prevention authority); and / or other suitable operations.

[0184] In some embodiments, the second set of fraud signals need not necessarily come from (or be generated by) a second bank, or by the particular bank of the particular Payee; rather, the second set of fraud signals can be obtained by a trusted server or by a clearinghouse server from a network-originating source of fraud signals or fraud-related information. For example, such trusted server or fraud-related information repository can inform the clearinghouse that: the second party in the inspected transaction, had been flagged in the past as a mule bank account or as a bank account that is possibly associated with money laundering and / or terror funding and / or illegal activities; or, that a third bank had already rejected or blocked another transaction in which another party (that is not the payer and not the payee of the inspected transaction) had attempted to transfer funds to the second party (the payee in the inspected transaction). Such information, that does not originate from the second bank and / or from the first bank, and / or that does not originate from the bank of the payee in the inspected transaction, and / or that does not originate from the bank of the payer in the inspected transaction, can be provided to the clearinghouse component or the trusted server and can be taken into account for generating the combined fraud-relatedness risk-score.

[0185] In some embodiments, the second set of fraud signals need not necessarily originate from a second bank, or from the particular bank of the particular Payee. Rather, such second set of fraud signals can be obtained, aggregated, or inferred by a trusted server or by a clearinghouse server that is capable of receiving and processing fraud-related information originating from external network sources, from independent risk-intelligence providers, or from cross-institution data feeds that convey transaction irregularities detected elsewhere in the payment ecosystem. In these embodiments, the clearinghouse component, or a trusted intermediary server acting under its authorization, functions as a neutral node that continuously collects, normalizes, and correlates data items received from multiple network-originating sources of fraud intelligence, without relying solely on direct signals from either of the banks involved in the inspected transaction.

[0186] For example, the trusted server can subscribe to or periodically retrieve information from one or more fraud-intelligence repositories, commercial or governmental, that maintaincontinuously updated registries of bank accounts, device fingerprints, IP addresses, or digital identities that have been associated with suspicious behavior. Such registries may include, for instance, data feeds indicating that certain accounts were previously frozen or restricted by other institutions, that certain account identifiers were linked to mule operations in previous investigations, or that certain routing numbers have been used in patterns consistent with layering or smurfing behavior typical in money-laundering schemes. In some cases, these data feeds can be provided via standardized APIs using secure transport protocols, such as mutual-TLS or token-based authentication, to ensure that only authorized clearinghouses or trusted servers receive the information.

[0187] In one implementation, the clearinghouse server can maintain a structured data repository that categorizes incoming external signals by their nature, reliability, and recency. For instance, a flag originating from a central intelligence clearing system indicating a confirmed mule account can be tagged with a high confidence score and a long validity period (e.g., 180 days), whereas a signal derived from a heuristic anomaly detector operating on public blockchain or peer-to-peer transaction data might receive a lower confidence value and a shorter retention period. When the clearinghouse processes a particular transaction between a first party (payer) and a second party (payee), it queries this repository to retrieve all matching indicators associated with either entity, with any device identifier linked to their access, or with any intermediary node through which the transaction has transited.

[0188] For example, if the trusted server learns from an independent source that the second party’s account had been flagged three months earlier by an unrelated third bank for receiving rapid-succession deposits from multiple newly opened accounts, that information can be incorporated as a secondary fraud signal, even though it did not originate from either the first or second bank involved in the present transaction. The clearinghouse may further enrich this information by examining whether the destination account had been subject to prior “return” transactions or refund reversals exceeding a threshold frequency, which often indicates potential laundering or mule activity.

[0189] In some embodiments, the trusted server aggregates such external fraud-related data into a unified fraud-risk context profile, in which each element of evidence contributes a weighted parameter to a combined fraud-relatedness risk-score. The weights may depend on factors such as the originating institution’s reliability, the type of indicator (e.g., confirmed fraud vs. suspected), the temporal proximity of the signal, and the degree of behavioral similarity between the historical pattern and the inspected transaction. The scoring engine can employ adaptive learning techniques that adjust these weights based on ongoing performancefeedback (such as false -positive or false-negative ratios observed across prior decisions), thereby continuously refining the contribution of each external fraud source.

[0190] In another example, the clearinghouse server may receive a network-originating alert that a third bank, unrelated to either the payer or payee, recently blocked an attempted transfer from another entity to the same payee. Even if this information was not shared through conventional interbank channels, the trusted fraud-information repository can forward such alerts through a dedicated fraud-exchange interface, enabling the clearinghouse to preemptively increase the risk score for any new incoming transaction targeting that same payee. This capability is particularly useful when dealing with fast-moving mule networks, in which fraudulent recipients rapidly migrate between institutions. By consolidating intelligence from multiple unrelated rejections, the clearinghouse effectively constructs a panoramic risk view that neither of the individual banks could form in isolation.

[0191] In some embodiments, the clearinghouse may also monitor aggregated network behavior that is independent of specific account identifiers but still informative of fraud probability. For instance, it may track the frequency with which a given device fingerprint, IP address, or digital certificate is associated with multiple account credentials across different banks within short intervals. Such cross-institution correlation, when performed by the trusted server under privacy-preserving data-exchange rules, allows detection of coordinated attacks or synthetic identity clusters. When the clearinghouse observes that the current payee’s access device was also involved in transactions previously rejected elsewhere, that pattern contributes to the second set of fraud signals, even though the signal originated externally to both the payer’s and payee’s banks.

[0192] In some implementations, the clearinghouse or trusted server may rely on multiple categories of external data sources. Examples may include: (a) industry consortium feeds (e.g., AML consortium databases); (b) law-enforcement watchlists or sanctions data; (c) cardnetwork or payment-scheme fraud alerts; (d) private-sector threat-intelligence services; (e) machine-learning-based anomaly detectors that operate over anonymized interbank transaction graphs.

[0193] Each external signal can be normalized into a canonical schema (e.g., JSON structure) containing attributes such as entity type, risk classification, time stamp, and confidence score. The clearinghouse can maintain a versioned index to ensure that downstream analyses can reference the exact signal set that was active when the risk score was computed.

[0194] In some embodiments, privacy and regulatory constraints are preserved through a combination of tokenization and federated evaluation. The clearinghouse may compute thefraud-relatedness score without directly disclosing identifying details of the payee or payer to the external data providers. Instead, it transmits hashed or pseudonymized identifiers for matching against encrypted fraud registries. Only the resulting match or non-match indicator, along with the corresponding confidence level, is returned. This architecture ensures compliance with data-protection frameworks such as GDPR or equivalent jurisdictional statutes while maintaining high-fidelity fraud detection.

[0195] In one example scenario, a payment transaction of $9,800 between a small retail merchant (payer) and an online supplier (payee) is inspected by the clearinghouse. The payer’s bank provides internal signals indicating no unusual account behavior. The payee’s bank, however, is temporarily offline and cannot provide real-time fraud assessment. The clearinghouse consults its trusted fraud repository and learns that an unrelated bank, two weeks earlier, rejected a payment to the same payee citing suspicion of mule activity. It also finds that the payee’s account number appears in a consortium feed tagged as “Tier-2 Risk: Rapid Inbound / Outbound Transfers.” Based on these two external signals, the clearinghouse assigns a heightened fraud-relatedness score to the transaction and routes it for manual verification.

[0196] In another example, if the external repository reveals that the same payee’s IP address was observed initiating logins for multiple accounts registered under different names but from the same device fingerprint, the clearinghouse interprets that pattern as indicative of coordinated account control. Even though the payee’s current bank has no active alert, the network-originating signals justify assigning an elevated risk score and possibly delaying the clearing process until confirmation from the issuing institutions is obtained.

[0197] In these embodiments, the combination of local (bank-generated) and external (network-originating) fraud signals enables the clearinghouse to produce a more comprehensive and timely fraud assessment. The architecture decouples the risk-scoring process from any single institution’s visibility, thereby allowing early detection of systemic threats that would otherwise remain hidden until after loss events occur. Furthermore, by using standardized data-exchange protocols, such as ISO 20022 extensions or JSON-based REST interfaces, the system facilitates seamless integration across heterogeneous banking infrastructures.

[0198] The trusted server or clearinghouse server thus functions as an intelligent intermediary that can obtain, store, and process second sets of fraud signals from networkoriginating sources, independent of the payer’s or payee’s banks. The resulting combined fraud-relatedness risk-score thus reflects both the direct transactional behavior and the broaderecosystem intelligence, improving detection of complex, distributed, or emerging fraud schemes while maintaining regulatory compliance and operational scalability.

[0199] The term “user” as used herein may include, for example: (i) a human user, operating a computerized device or an electronic device (e.g., a laptop computer, a desktop computer, a smartphone, a tablet); and / or (ii) a software module or autonomous software module, or a hardware unit, or a hybrid hardware-and-software unit, or an Artificial Intelligence (Al) based module or “hot” or agentic unit that is configured or programmed or prompted to perform one or more operations and / or to interact with a computerized system and / or to engage with a computerized system; (iii) a humanoid robot or other type of robot or machine that is configured or programmed to perform interactions and / or to access resources and / or to interact with a computerized system and / or to engage with a computerized system.

[0200] Optionally, an Artificial Intelligence (Al) / Machine Learning (ML) Engine 144 may be part of system 100, and may perform Al / ML based analysis of fraud signals and / or may generate insights indicating whether a particular transaction (or, a party to a transaction) is more likely to be fraud-related or illegitimate; and / or may generate combined fraud-relatedness scores or insights.

[0201] In some embodiments, optionally, the Al / ML Engine 144 may be configured to compute a hybrid fraud-relatedness score by performing multi-modal feature fusion over signals originating independently from the Payer Bank and from the Payee Bank, and optionally from a trusted third-party clearinghouse. The Al / ML Engine 144 may receive, as inputs, bank-side behavioral telemetry, historical transaction attributes, device and channel metadata, merchant category and geospatial features, velocity aggregates, sanctions and watchlist matches, and per-party reputation metrics computed locally by each bank. Where privacy constraints apply, the Al / ML Engine 144 can operate on salted and keyed hashed values of identifiers such as account numbers, device IDs, or email handles, along with cryptographically blinded aggregates that preserve distributional structure. The Al / ML Engine 144 may apply learned encoders that project heterogeneous features into a common latent space, for example using gradient-boosted decision tree embeddings for tabular attributes combined with attention-based encoders for sequential clickstream evidence. The Al / ML Engine 144 can be trained on labeled outcomes that include confirmed fraud, chargebacks, manual review dispositions, and legitimate completions, using class-imbalance strategies such as focal loss, calibrated weighting, or positive -unlabeled learning. During inference, the Al / ML Engine 144 can produce a calibrated probability and a decomposed set of sub-scores aligned to signal families, along with confidence intervals derived via Monte Carlo dropout orconformal prediction. The Al / ML Engine 144 may also produce optional control outputs including recommended action codes, suggested case-routing tiers, and human-explainable rationales derived from SHAP value aggregations, partial-dependence probes, or counterfactual perturbations constrained to policy-safe feature changes. The resulting outputs can be consumed by the system’s decision orchestration layer to permit, decline, queue for review, or request step-up verification, with per-jurisdiction policy bindings applied before final actuation.

[0202] In some embodiments, optionally, the Al / ML Engine 144 may be configured to perform cross-institution entity resolution on privacy-preserving identifiers to detect whether the two banks’ parties, devices, or instruments are statistically likely to correspond to previously observed actors or clusters implicated in risk. The Al / ML Engine 144 may receive salted hashes of identifiers, Bloom-filter encodings of token sets, locality-sensitive hashes of behavioral n-grams, and time-bucketed sketches of transaction signatures generated independently by each bank or by the clearinghouse. The Al / ML Engine 144 can train a contrastive representation model that pulls together encodings from the same latent entity across institutions while pushing apart unrelated encodings; the negative sampling can be guided by time overlap, geography, and merchant topology constraints. The model can incorporate privacy layers such as secure enclave execution for intermediate joins and differential privacy noise addition on gradient updates when federated training is used. Outputs from this function can include an entity-link confidence score, a cluster identifier for downstream correlation, and a set of canonicalized features that summarize the cross-bank footprint without revealing raw identities. The Al / ML Engine 144 may further attach provenance metadata that describes which evidence types contributed to a linkage, enabling auditability and selective revocation if a particular signal is later deemed unreliable. Training data can include historical co-occurrence events where post-hoc investigations established cross-bank commonality, along with synthetic perturbations that stress the model on nearcollision cases, such as devices reused after factory reset or proxy networks that distort IP neighborhoods. The Al / ML Engine 144 can periodically retrain on sliding windows to capture drift in user behavior and adversarial aliasing tactics, while preserving stability via elastic weight consolidation or teacher- student distillation that retains known good alignments.

[0203] In some embodiments, optionally, the Al / ML Engine 144 may be configured to conduct temporal anomaly detection on transaction sequences and session-level behaviors, enabling early recognition of takeover, mule orchestration, or rapid pivot campaigns. Inputs can include timestamped events such as login attempts, credential resets, beneficiary edits,limits changes, device enrollments, step-up challenges, and payment initiations, each tagged with channel, device, and geo attributes and with bank-side risk micro-scores. The Al / ML Engine 144 can maintain per-entity sequence models, for example gated recurrent units or transformer encoders with positional embeddings, that learn typical orderings and dwell time distributions. The Al / ML Engine 144 may compute likelihoods for observed sequences under the learned model and flag low-likelihood trajectories or sudden regime shifts measured by cumulative sum detectors, exponentially weighted moving variance, or change -point inference. Training can be semi-supervised: the model first fits normality on large volumes of unlabeled sequences, then fine-tunes with small sets of labeled attack episodes and analyst-validated anomalies. The Al / ML Engine 144 can output an anomaly score, a change-point index, and a diagnostic bundle that highlights the events and intervals most responsible for the deviation. When sequence evidence from both banks is available through the clearinghouse, the Al / ML Engine 144 can align timelines using clock- skew-tolerant matching and examine cross-bank lag structures, such as rapid cascades where suspicious edits at the Payer Bank are followed by high-value deposits at the Payee Bank. The Al / ML Engine 144 may enforce privacy by learning only from feature trajectories derived from hashed identifiers and by discarding raw free-text fields unless locally permitted. The anomaly outputs can be fused with static entity risk to escalate cases that show both chronic high risk and acute abnormal motion.

[0204] In some embodiments, optionally, the Al / ML Engine 144 may be configured to construct and analyze a dynamic counterparty interaction graph to identify collusive structures, mule rings, and high-risk merchant ecosystems. The Al / ML Engine 144 may ingest edge declarations from both banks that describe transfers between hashed parties, with edge attributes for amount, currency, method, MCC, device overlap, and temporal cadence. The engine can maintain a time-evolving heterogeneous graph where nodes represent parties, devices, merchants, and instruments, and edges capture transactions, co-usage events, and shared attributes. The Al / ML Engine 144 may train a graph neural network with temporal attention that generates node and edge embeddings sensitive to both local motifs and long-range diffusion. Training labels can be obtained from adjudicated investigations, law-enforcement feedback, chargeback clusters, or weak supervision rules, such as triads with short-cycle fund flows and high return ratios. The Al / ML Engine 144 can compute graphbased outputs that include community-risk scores, edge suspiciousness probabilities, and pathway explanations that trace minimal subgraphs connecting a candidate transaction to known bad anchors. The engine can also perform counterfactual pruning to determine whether risk persists when certain edges are removed, which supports robust reasoning in the presenceof noisy links. For privacy, the graph can be built over hashed node IDs and privacy-budgeted degree statistics, while the clearinghouse enforces k-anonymity constraints on communities before sharing. The Al / ML Engine 144 may expose programmatic APIs that allow the decision layer to ask targeted questions, such as the measured centrality of the Payee party in suspected laundering circuits or the existence of recent flows from the Payer party to high-risk clusters. Outputs can guide holds, enhanced due diligence, or limits throttling, and can be archived with lineage so that regulators can reconstruct how a graph signal influenced a decision.

[0205] In some embodiments, optionally, the Al / ML Engine 144 may be configured to perform adversarial-robust inference and self-calibration in the presence of distribution shift and active evasion by hostile actors. The Al / ML Engine 144 may receive input batches that include real-time transactions and optional synthetic variants generated by an internal perturbation generator that applies plausible but policy-safe edits to amounts, timings, device fingerprints, and routing paths. During training, the Al / ML Engine 144 can employ adversarial training where the base model is optimized to maintain risk-ranking under worst-case perturbations sampled from a bounded threat model, for example L-infinity perturbations on standardized tabular features or discrete token substitutions within categorical vocabularies. The Al / ML Engine 144 may fine-tune calibration using temperature scaling or isotonic regression on recent cohorts, and it can monitor calibration drift via expected calibration error and Brier score on post-decision outcomes. The engine can also implement online learning safeguards: candidate updates are evaluated in a shadow deployment that mirrors production distributions, and model-change approvals are gated on pre-registered metrics with guardrails that detect performance regressions on protected segments or rare but critical scenarios. Inputs may include regulator-defined fairness attributes where permitted, or, alternatively, proxy stability metrics that avoid sensitive attributes but still detect disparate impact. Outputs from this function can include calibrated probabilities, confidence intervals, shift diagnostics that quantify feature-space drift, and resilience scores that estimate the model’s sensitivity to adversarial edits. The Al / ML Engine 144 can record a cryptographic digest of the training configuration, data snapshot identifiers, and hyperparameters to ensure auditability, and it can support rollback by retaining the previous model as a quorum-approved fallback. The overall effect is a scoring surface that remains stable and interpretable even as actors attempt to game thresholds.

[0206] In some embodiments, optionally, the Al / ML Engine 144 may be configured to optimize operational policy, case triage, and human-in-the-loop review through reinforcement-learning-from-feedback coupled with cost-aware decision simulation. Inputs to this function can include historical decision logs that record model scores, human override actions, downstream outcomes such as confirmed fraud or customer attrition, and cost parameters that encode chargeback exposure, investigation labor time, step-up friction, and regulatory penalties. The Al / ML Engine 144 may learn a policy that maps score vectors and context to an action set including approve, decline, hold, or request additional verification, with stochastic exploration constrained to regulator-safe regions. The training procedure can combine off-policy evaluation with inverse propensity weighting to avoid bias from prior heuristics, and can simulate counterfactual outcomes using doubly robust estimators seeded with approved what-if rulesets. The Al / ML Engine 144 can output recommended operating points, queue prioritization scores for analysts, and suggested evidence checklists tailored to the transaction’s feature footprint, which shortens review time while preserving coverage. The engine may also learn analyst embeddings that capture reviewer strengths and load profiles to route complex cases to specialists while respecting compliance constraints. Fine-tuning can incorporate direct analyst feedback where reviewers upvote or downvote rationale snippets or mark features as misleading, which is then distilled into the model through preference optimization. The Al / ML Engine 144 can expose a transparent changelog for any policy shift, along with re -play able simulations that show the projected change in false positives, false negatives, and customer friction at the portfolio level and per jurisdiction. In privacy-constrained deployments, simulations operate on hashed identifiers and on summary statistics computed locally by each bank, with the clearinghouse providing only aggregate lift metrics.

[0207] Some embodiments may include, or may utilize, or may operate in conjunction with, local and / or co-located and / or remote and / or cloud-based servers or computers that are configured to run, or that implement, an Artificial Intelligence (Al) tool or unit or engine, or a unit or engine that utilize or that comprises a Neural Network (NN) or an Artificial NN (ANN) or a Convolutional NN (CNN) or a Recurrent NN (RNN), or a unit or engine that utilizes or the comprises a Machine Learning (ML) or a Deep Learning (DL) model or engine, or a unit or engine that is trained to identify or recognize or extract or deduce patterns from data or dataset(s) and / or to autonomously perform feature extraction and / or to generate prediction or estimations or decisions in a manner that is not based on deterministic pre-programmed prediction rules or decision rules or estimation rules, or a unit or engine or model that is trained or configured via supervised learning and / or self-supervised learning and / or unsupervised learning and / or reinforcement learning, or a unit or engine that implements or utilizes or comprises a Large Language Model (LLM) or a large Vision-and-Language Model (VLM) ora large Language-and-Vision Model (LVM) or a Large Multi-Modalities Model or a Large Multiple-Modalities Model (LMM or LMMM) such as OpenAI Chat-GPT or Microsoft Copilot or Anthropic Claude or Meta Llama or Google Gemini or Mistral Al or Grok xAI or a Vision-Language- Action (VLA) model (e.g., Google Gemini Robotics), or a unit or model that specializes in Natural Language Processing (NLP) tasks such as language processing generation and / or image processing and generation and / or document processing and generation and / or video processing and generation, or a unit or model or engine that comprise or utilize a set of Generative Pretrained Transformers (GPTs), or a unit or model that can be guided or instructed or queried via textual prompts and / or via prompt engineering, or a unit or model that utilizes tokens or tokenized information in order to generate or predict or provide one or more next tokens or subsequent tokens, or a unit or engine that utilizes embeddings or vectorized databases to represent information, or a unit or engine that perform enrichment / augmentation of information or enrichment / augmentation of context that is provided as input to such model by using Retrieval-Augmented Generation (RAG) or other augmentation / enrichment techniques, or a unit or engine that is configured to train or re-train or fine-tune a model or to modify weights and / or biases and / or parameters and / or coefficients of a model, or a unit or controller that controls or commands or provides prompts to one or more of the above-mentioned models that are arrange in parallel or in series or as a matrix or array or cascade, or a unit or engine that obtains or aggregates or combines outputs from two or more of such models or units.

[0208] In accordance with some embodiments, the utilized LLM can be fine-tuned or configured or modified or trained or post-trained or re-trained to specialize in a particular task or a particular type of tasks. Some benefits and features of such fine-tuning (or re-training) may include, for example: (1) Automated Analysis, as Language models can process and analyze vast amounts of data at speeds far beyond human capabilities, and this allows for the real-time or near-real-time processing of data and efficient delivery of actionable outputs. (2) Pattern Recognition, as advanced language models are adept at recognizing patterns within data, including the identification of anomalies or abnormal items or suspicious items that may indicate an anomaly or a security threat or other possible risks to the organization or to the user. (3) Natural Language Processing (NLP), as the LLM can analyze and process information such as unstructured data, raw texts from the Internet, professional chatters, blog posts, social media posts and content, forum posts, news articles, or other types of unstructured information; and the LLM can interpret and extract meaningful information and insights from such unstructured data, turning it into actionable intelligence. (4) Contextual Understanding, as the LLM canprovide context to the data being analyzed, and can “understand” or detect or utilize the nuances and implications of certain terms within the relevant domain, which helps in accurately assessing the nature and the intent of user-provided prompts or queries or directives, as well as the assistive information that can be extracted from the context that is fed to the LLM. (5) Data Correlation, as the LLM can process and analyze data from multiple sources, and can thus correlate seemingly unrelated data-items or documents or messages to uncover or to extract a pattern or a coordinated scheme (e.g., identifying a coordinated attack campaign from a plurality of discrete signals or messages, or identifying the tactics, techniques, and procedures (TTPs) used by threat actors). (6) Trend Analysis, as the LLM can identify emerging trends by analyzing the frequency and context of particular data-items, posts, content-items, discussions, signals, messages, and / or related reports. (7) Scalability, as the volume of data and documentation grows, the LLM can efficiently scale to handle the increased load, ensuring that analysis capabilities remain consistent regardless of the amount of data. (8) Reduction of False Positive / False Negative Errors, as the LLM can be configured to learn from historical data during the fine-tuning process and by using RAG, and thus the LLM can gradually reduce the number and / or the rate and / or the frequency of false positive errors or false negative errors. (9) Enhanced Decision Making, as the comprehensive analysis provided by the LLM can assist both human professionals and automated decision-making tools in making more informed decisions. (10) Continuous Learning, as the LLM can be configured to continuously learn and adapt to new data, thereby improving its accuracy and relevance over time; and this can be particularly useful in a domain or field that have an ever-evolving landscape of information. (11) Multilingual Support, as the LLM can process and understand multiple natural languages (e.g., English, Spanish, French), thereby supporting queries or prompts or requests or directives that originate from a diversity of users of a multi-cultural or multi-region or global organization or an otherwise multi-lingual team. (12) Cost Efficiency, as the utilization of LLMs can automate or can hasten one or more processes or actions of an organizational process, thereby reducing the manual workload on human team-members, and possibly reducing operational and human errors.

[0209] The fine-tuning (or re-training) of the LLM may be performed based on relevant domain knowledge, or based on particular data or documents or information that pertains to a specific field or task or type-of-task. For example, the large language model’s weights or biases, which have been pre-trained on a vast corpus of general data, are further adjusted to perform well on a specific task or domain based on a dataset that is enriched and labeled for this task. In a demonstrative example, the LLM fine-tuning may include: (a) Initialization, asthe LLM starts with weights that have been learned during its pre-training phase; (b) Further Training, as the LLM is fine-tuned using a task-specific dataset, which is typically smaller than the one used for pre-training and contains examples of the specific task that the LLM needs to perform; (c) Parameter Adjustment, such that the LLM’s parameters (weights and biases) are modified or updated to minimize the loss function specific to the task, such as using gradient descent and back-propagation; (d) Learning Rate Adjustment, as a lower learning rate can be used in the fine-tuning phase compared to the initial pre-training phase, in order to make smaller adjustments to the weights and / or to avoid over-writing of the pre-existing knowledge encoded in the model, and / or to ensure that the large language model does not “forget” the initial information on which it was trained while learning the new domain-specific capabilities; (e) Regularization, by selectively using techniques like early stopping or dropout, in order to prevent over-fitting of the model to the fine-tuning dataset, thereby ensuring that the model still retains its generalizing capability; (f) Freezing Layers, such that in some situations only a portion of the model’s layers are fine-tuned while other layers are intentionally “frozen” or remain unmodified, such as, the last few layers of the model are fine-tuned because they are more task-specific, while earlier layers remain frozen and unmodified in order to capture general language features; (g) Other model fine-tuning operations and processes that balance between (i) retaining the vast knowledge that the LLM had gained during initial training or pretraining and (ii) sufficiently adapting the LLM to excel and to specialize in performing a particular task or type-of-tasks, such that the fine-tuned LLM would “understand” (process, analyze) the inputs and would generate outputs in a way that is tailored to the requirements of the particular application.

[0210] Some embodiments may provide a computerized method and system that generates a combined inter-institution fraud-relatedness risk-score for an inspected transaction in which a first party of a first bank is transferring funds to a second party of a second bank; by performing: (a) receiving from the first bank a first set of fraud-related signals, that are generated based on information that the first bank has about the first party and about the inspected transaction; (b) receiving from the second bank a second set of fraud-related signals, that are generated based on information that the second bank has about the second party and about the inspected transaction; (c) generating the combined inter-institution fraud-relatedness risk-score, based on an analysis that takes into account both: (cl) the first set of fraud-related signals that were generated by the first bank based on information that the first bank has about the first party and about the inspected transaction, and (c2) the second set of fraud-related signals that were generated by the second bank based on information that the second bank hasabout the second party and about the inspected transaction; (d) providing the combined interinstitution fraud-relatedness risk-score to at least one of: the first bank, the second bank; and if the combined inter-institution fraud-relatedness risk-score is greater than a pre-defined threshold value, then: triggering one or more pre-defined fraud mitigation operations.

[0211] In some embodiments, the first set of fraud-related signals are generated exclusively based on information that the first bank has about the first party and about the inspected transaction; wherein the second set of fraud-related signals are generated exclusively based on information that the second bank has about the second party and about the inspected transaction.

[0212] In some embodiments, the first set of fraud-related signals are generated exclusively based on information that the first bank has about the first party and about the inspected transaction; wherein the second set of fraud-related signals are generated based on information that is obtained from a trusted server that is external to the first bank and is external to the second bank, that indicates (a) that another payment transaction was performed towards said second party concurrently and / or within the past T minutes (wherein T is a pre-defined threshold value, such as 30 or 60), and / or (b) that another payment transaction was attempted towards said second party concurrently and / or within the past T minutes and was refused or blocked or rejected or was otherwise associated with a fraud-relatedness signal, and / or (c) that another transaction (e.g., an outgoing payment transaction, rather than an incoming payment transaction) was performed by said second party (or its bank account) concurrently and / or within the past T minute, and / or (d) that another payment transaction (e.g., an outgoing payment transaction, rather than an incoming payment transaction) was attempted by said second party (or its bank account) concurrently and / or within the past T minutes and was refused or blocked or rejected or was otherwise associated with a fraud-relatedness signal, and / or (e) that the second party (or its bank account) has been associated with a fraud-related signal at least N times in the past D days (wherein N and D are pre-defined threshold value; such as, N=2 and D=7), and / or (f) that the second party (or its bank account) has been associated with an attempted-and-rejected incoming transaction (towards the second bank) in the past T minutes or D days, and / or (g) that the second party (or its bank account) has been associated with at least N attempted-and-rejected incoming transactions (towards the second bank) in the past D days.

[0213] In some embodiments, the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a proxy server to submit the inspected transaction.

[0214] In some embodiments, the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction, is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a Virtual Private Network (VPN) to submit the inspected transaction.

[0215] In some embodiments, the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction, is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a Virtual Machine (VM) to submit the inspected transaction.

[0216] In some embodiments, the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction, is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a Remote Access module to submit the inspected transaction.

[0217] In some embodiments, the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction, is generated based on an analysis that takes into account a data-entry rhythm or a data-entry cadence that characterizes data-entry by the first party while it entered data of the inspected transaction through an interface of the first bank.

[0218] In some embodiments, the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction, is generated based on an analysis that takes into account data from a hardware unit of an electronic device of the first party while it entered data of the inspected transaction through an interface of the first bank; wherein said hardware component is at least one of: an accelerometer of the electronic device, a gyroscope of the electronic device, a compass unit of the electronic device, a device orientation sensor of the electronic device.

[0219] In some embodiments, the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction, is generated based on a data-entry analysis process, that analyzes data-entry interactions of the first party through an interface of the first bank, and that determines that said data-entry interactions of the first party are more likely to be associated with operations performed by an automated script than with operations performed by a human user.

[0220] In some embodiments, the second set of fraud-related signals that are generated based on information that the second bank has about the second party and about the inspectedtransaction, is generated based on an analysis that takes into account an automatic detection that the second party has utilized at least one of: a Proxy Server to access the second bank, a Virtual Private Network (VPN) to access the second bank, a Virtual Machine (VM) to access the second bank, a Virtual Machine (VM) to access the second bank, a Remote Access module to access the second bank.

[0221] In some embodiments, the second set of fraud-related signals that are generated based on information that the second bank has about the second party and about the inspected transaction, is generated based on an analysis that takes into account a data-entry rhythm or a data-entry cadence that characterizes data-entry by the first party while it entered data of the inspected transaction through an interface of the first bank.

[0222] In some embodiments, the second set of fraud-related signals that are generated based on information that the second bank has about the second party and about the inspected transaction, is generated based on a data-entry analysis process, that analyzes data-entry interactions of the second party through an interface of the second bank, and that determines that said data-entry interactions of the second party are more likely to be associated with operations performed by an automated script than with operations performed by a human user.

[0223] In some embodiments, the combined inter-institution fraud-relatedness risk-score is generated for the inspected transaction by further taking into account a signal, obtained from a trusted server, indicating that at least one of: the first party, the second party, had previously been involved in another banking transaction that had already been estimated to be one of: a money laundering related transaction, a terror funding related transaction, a transaction involving a mule bank account.

[0224] In some embodiments, the combined inter-institution fraud-relatedness risk-score is generated for the inspected transaction by further taking into account a signal indicating that at least one of: the first party, the second party, is estimated to be performing banking operations that are dictated by an attacker performing a Vishing attack in accordance with an attack playbook.

[0225] In some embodiments, the combined inter-institution fraud-relatedness risk-score is generated in real time or in near-real-time, immediately upon submission of data of the inspected transaction, based on real time analysis of fraud signals.

[0226] In some embodiments, the first set and the second set are timestamped, versioned, and signed by their originating banks to authenticate provenance and freshness.

[0227] In some embodiments, each bank transmits, instead of an account number, a cryptographic hash of its party identifier, preventing direct reconstruction of party identityacross institutions. In some embodiments, hashed party identifiers are produced using institution-specific keys via HMAC, enabling consistent joining while limiting cross-bank linkage outside authorized workflows. In some embodiments, the method further comprises: rotating salts and / or keys for generating said hashed identifiers on a periodic schedule, with invalidation of stale hashes after rotation completes. In some embodiments, the combined interinstitution fraud-relatedness risk-score is computed inside a hardware-backed secure enclave that enforces encrypted memory and remote attestation before execution. In some embodiments, the method further comprises: encrypting the first and second sets in transit and at rest using mutually authenticated transport and field-level encryption for sensitive attributes.

[0228] In some embodiments, generating the first set includes device fingerprint features, login telemetry, and session velocity for the first party related to the inspected transaction.

[0229] In some embodiments, generating the second set includes merchant profile features, beneficiary account tenure, and recent chargeback indicators associated with the second party.

[0230] In some embodiments, the analysis applies graph-based features that consider historical interactions between inter-institutional accounts and inter-party devices.

[0231] In some embodiments, the method further comprises: calibrating or modifying the combined inter-institution fraud-relatedness risk-score in accordance with institution-specific acceptance policies. In some embodiments, the pre-defined threshold value is dynamically selected based on transaction channel, amount bands, jurisdiction, and model version performance characteristics.

[0232] In some embodiments, the method further comprises: automatically generating at least one of: (i) an explanation vector attributing fractional contributions to features originating from the first bank and / or from the second bank; (ii) a group of data-points that explain one or more risk factors that contributed to the generated risk-score.

[0233] In some embodiments, triggering the fraud mitigation operations comprises step-up authentication, temporary hold placement, and message delivery to designated operational response queues. In some embodiments, differential privacy noise is applied to aggregate analytics derived from the first and second sets, preserving utility for monitoring without reidentification. In some embodiments, entity resolution across institutions uses blinded tokenbased joins that require dual consent flags before linkage, recorded in a shared governance registry. In some embodiments, the method further comprises: monitoring for data drift by comparing feature distributions from each institution against baselines, triggering retraining workflows upon deviations.

[0234] In some embodiments, the analysis includes constraints comparing first party origination location with second party receiving context to detect improbable travel patterns.

[0235] In some embodiments, the method generates and utilizes overlays (or conversion rules, or character conversion rules) that standardize names using transliteration rules prior to matching against domestic and international watchlists (e.g., changing “Andre” to “Andre”).

[0236] In some embodiments, model training occurs using federated learning that keeps raw records within each bank while sharing gradients or parameters under privacy controls.

[0237] In some embodiments, the method comprises: maintaining model version lineage, with rollback to a previously validated model if post-deployment monitoring exceeds predefined error tolerances.

[0238] In some embodiments, the method comprises: rejecting scoring requests containing malformed timestamps, unsigned payloads, and / or mismatched schema versions; and recording rejection reasons for diagnostics.

[0239] In some embodiments, the method comprises: providing replay protection using nonces or sequence counters so previously observed messages cannot be reused to influence scoring outcomes.

[0240] In some embodiments, jurisdictional routing are used to ensure that features used in the analysis comply with regional data localization and sectoral rules before participation.

[0241] In some embodiments, the method comprises: enforcing human-in-the-loop review queues that prioritize inspected transactions with near-threshold scores or conflicting signals between the two institutions.

[0242] In some embodiments, the combined inter-institution risk score incorporates uncertainty estimates that account for missing features from either institution during computation. In some embodiments, the method comprises: performing pre-decision counterfactual tests comparing outcomes using only the first set, only the second set, and both sets together. In some embodiments, mitigation triggers include: sending a standardized case package containing selected features, explanations, and metadata to both banks’ case management systems.

[0243] In some embodiments, the trusted third-party server that generates the combined risk-score may take into account: (i) the age (e.g., in days) of the bank account of the first party at the first bank, and / or (ii) the age (e.g., in days) of the bank account of the second party at the second bank. It is noted carefully that this discussion revolves around the age of the Bank Account, namely the number of days or years that elapsed since the Bank Account was openor since it was seen or observed “in the wild” as involved in a banking transaction; and not the age (in years) of the person who owns the bank account.

[0244] In some embodiments, the trusted third-party server may deduce the age of a bank account without necessarily receiving this data-item from the relevant bank; for example, the trusted third-party server has analyzed a transaction in which the account of User Adam sent money to the account of User Bob on February 5; later, on June 5, the trusted third-party server has to generate a combined inter-institution risk score or fraud-relatedness score for a new transaction in which an account of User Carla sends money to the account of User Bob; and therefore, the trusted third-party server already knows that the account of User Bob is at least 4 months old. Similarly, later, on August 5, the trusted third-party server has to generate a combined inter-institution risk score or fraud-relatedness score for a new transaction in which an account of User Adam sends money to the account of User David; and therefore, the trusted third-party server already knows that the account of User Adam is at least 6 months old.

[0245] In some embodiments, the combined inter-institution risk-score further takes into account an age value of the first party’s bank account at the first bank. In some embodiments, additionally or alternatively, the combined inter-institution risk-score further takes into account an age value of the second party’s bank account at the second bank. Optionally, the trusted third-party server deduces the age of an account based on having previously processed a transaction involving said account. Optionally, the trusted third-party server estimates the account’s age without receiving it explicitly from the relevant bank or party, by referencing timestamped evidence of prior observed transactions.

[0246] Features or signals or characteristics that are discussed above with regard to the first party and / or the first bank and / or the first account and / or the first user, may be utilized -additionally or alternatively - as if they were discussed with regard to the second party and / or the second bank and / or the second account and / or the second user; and vice versa.

[0247] Some embodiments provide a system comprising: one or more hardware processors, that are configured to execute code, and that are operably associated with one or more memory units; wherein the one or more hardware processors are configured to perform a method as described.

[0248] Some embodiments provide a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the machine to perform a method as described.

[0249] Although portions of the discussion herein relate, for demonstrative purposes, to wired links and / or wired communications, some embodiments of the present invention are notlimited in this regard, and may include one or more wired or wireless links, may utilize one or more components of wireless communication, may utilize one or more methods or protocols of wireless communication, or the like. Some embodiments may utilize wired communication and / or wireless communication.

[0250] Some embodiments may be implemented by using hardware units, software units, processors, CPUs, DSPs, GPUs, integrated circuits (ICs), memory units, storage units, wireless communication modems or transmitters or receivers or transceivers, cellular transceivers, a power source, input units, output units, Operating System (OS), drivers, applications, and / or other suitable components.

[0251] Some embodiments may be implemented by using a special-purpose machine or a specific -purpose that is not a generic computer, or by using a non-generic computer or a nongeneral computer or machine. Such system or device may utilize or may comprise one or more units or modules that are not part of a “generic computer” and that are not part of a “general purpose computer”, for example, cellular transceivers, cellular transmitter, cellular receiver, GPS unit, location-determining unit, accelerometer(s), gyroscope(s), device-orientation detectors or sensors, device-positioning detectors or sensors, or the like.

[0252] Some embodiments may be implemented by using code or program code or machine -readable instructions or machine-readable code, which is stored on a non-transitory storage medium or non-transitory storage article (e.g., a CD-ROM, a DVD-ROM, a physical memory unit, a physical storage unit), such that the program or code or instructions, when executed by a processor or a machine or a computer, cause such device to perform a method in accordance with the present invention.

[0253] Some embodiments may be utilized with a variety of devices or systems having a touch-screen or a touch-sensitive surface; for example, a smartphone, a cellular phone, a mobile phone, a smart-watch, a tablet, a handheld device, a portable electronic device, a portable gaming device, a portable audio / video player, an Augmented Reality (AR) or Virtual Reality (VR) or Mixed Reality (XR) device or headset or gear, a “kiosk” type device, a vending machine, an Automatic Teller Machine (ATM), a laptop computer, a desktop computer, a vehicular computer, a vehicular dashboard, a vehicular touch-screen, or the like.

[0254] The system(s) and / or device(s) of some embodiments may optionally comprise, or may be implemented by utilizing suitable hardware components and / or software components; for example, processors, processor cores, Central Processing Units (CPUs), Digital Signal Processors (DSPs), circuits, Integrated Circuits (ICs), controllers, memory units, registers, accumulators, storage units, input units (e.g., touch-screen, keyboard, keypad, stylus, mouse,touchpad, joystick, trackball, microphones), output units (e.g., screen, touch-screen, monitor, display unit, audio speakers), acoustic microphone(s) and / or sensor(s), optical microphone(s) and / or sensor(s), laser or laser-based microphone(s) and / or sensor(s), wired or wireless modems or transceivers or transmitters or receivers, GPS receiver or GPS element or other location-based or location-determining unit or system, network elements (e.g., routers, switches, hubs, antennas), and / or other suitable components and / or modules.

[0255] The system(s) and / or devices of some embodiments may optionally be implemented by utilizing co-located components, remote components or modules, “cloud computing” servers or devices or storage, client / server architecture, peer-to-peer architecture, distributed architecture, and / or other suitable architectures or system topologies or network topologies.

[0256] In accordance with some embodiments, calculations, operations and / or determinations may be performed locally within a single device, or may be performed by or across multiple devices, or may be performed partially locally and partially remotely (e.g., at a remote server) by optionally utilizing a communication channel to exchange raw data and / or processed data and / or processing results.

[0257] Some embodiments may be implemented by using a special-purpose machine or a specific -purpose device that is not a generic computer, or by using a non-generic computer or a non-general computer or machine. Such system or device may utilize or may comprise one or more components or units or modules that are not part of a “generic computer” and that are not part of a “general purpose computer”, for example, cellular transceivers, cellular transmitter, cellular receiver, GPS unit, location-determining unit, accelerometer(s), gyroscope(s), device-orientation detectors or sensors, device -positioning detectors or sensors, or the like.

[0258] Some embodiments may be implemented as, or by utilizing, an automated method or automated process, or a machine-implemented method or process, or as a semi-automated or partially-automated method or process, or as a set of steps or operations which may be executed or performed by a computer or machine or system or other device.

[0259] Some embodiments may be implemented by using code or program code or machine -readable instructions or machine -readable code, which may be stored on a non-transitory storage medium or non-transitory storage article (e.g., a CD-ROM, a DVD-ROM, a physical memory unit, a physical storage unit, a Flash drive), such that the program or code or instructions, when executed by a processor or a machine or a computer, cause such processor or machine or computer to perform a method or process as described herein. Such code or instructions may be or may comprise, for example, one or more of: software, a softwaremodule, an application, a program, a subroutine, instructions, an instruction set, computing code, words, values, symbols, strings, variables, source code, compiled code, interpreted code, executable code, static code, dynamic code; including (but not limited to) code or instructions in high-level programming language, low-level programming language, object-oriented programming language, visual programming language, compiled programming language, interpreted programming language, C, C++, C#, Java, JavaScript, SQL, Ruby on Rails, Go, Cobol, Fortran, ActionScript, AJAX, XML, JSON, Lisp, Eiffel, Verilog, Hardware Description Language (HDL), BASIC, Visual BASIC, MATLAB, Pascal, HTML, HTML5, CSS, Dart, Perl, Python, PHP, machine language, machine code, assembly language, or the like.

[0260] Discussions herein utilizing terms such as, for example, “processing”, “computing”, “calculating”, “determining”, “establishing”, “analyzing”, “checking”, “detecting”, “measuring”, or the like, may refer to operation(s) and / or process(es) of a processor, a computer, a computing platform, a computing system, or other electronic device or computing device, that may automatically and / or autonomously manipulate and / or transform data represented as physical (e.g., electronic) quantities within registers and / or accumulators and / or memory units and / or storage units into other data or that may perform other suitable operations.

[0261] Some embodiments of the present invention may perform steps or operations such as, for example, “determining”, “identifying”, “comparing”, “checking”, “querying”, “searching”, “matching”, and / or “analyzing”, by utilizing, for example: a pre-defined threshold value to which one or more parameter values may be compared; a comparison between (i) sensed or measured or calculated value(s), and (ii) pre-defined or dynamically-generated threshold value(s) and / or range values and / or upper limit value and / or lower limit value and / or maximum value and / or minimum value; a comparison or matching between sensed or measured or calculated data, and one or more values as stored in a look-up table or a legend table or a list of reference value(s) or a database of reference values or ranges; a comparison or matching or searching process which searches for matches and / or identical results and / or similar results and / or sufficiently-close results (e.g., within a pre-defined threshold level of similarity; such as, within 5 percent above or below a pre-defined threshold value), among multiple values or limits that are stored in a database or look-up table; utilization of one or more equations, formula, weighted formula, and / or other calculation in order to determine similarity or a match between or among parameters or values; utilization of comparator units, lookup tables, threshold values, conditions, conditioning logic, Boolean operator(s) and / or other suitable components and / or operations.

[0262] The terms “plurality” and “a plurality”, as used herein, include, for example, “multiple” or “two or more”. For example, “a plurality of items” includes two or more items.

[0263] References to “one embodiment”, “an embodiment”, “demonstrative embodiment”, “various embodiments”, “some embodiments”, and / or similar terms, may indicate that the embodiment(s) so described may optionally include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, although it may. Repeated use of the phrase “in some embodiments” does not necessarily refer to the same set or group of embodiments, although it may.

[0264] As used herein, and unless otherwise specified, the utilization of ordinal adjectives such as “first”, “second”, “third”, “fourth”, and so forth, to describe an item or an object, merely indicates that different instances of such like items or objects are being referred to; and does not intend to imply as if the items or objects so described must be in a particular given sequence, either temporally, spatially, in ranking, or in any other ordering manner.

[0265] Some embodiments may comprise, or may be implemented by using, an “app” or application which may be downloaded or obtained from an “app store” or “applications store”, for free or for a fee, or which may be pre-installed on a computing device or electronic device, or which may be transported to and / or installed on such computing device or electronic device.

[0266] Functions, operations, components and / or features described herein with reference to one or more embodiments of the present invention, may be combined with, or may be utilized in combination with, one or more other functions, operations, components and / or features described herein with reference to one or more other embodiments of the present invention. The present invention may comprise any possible combinations, re-arrangements, assembly, re-assembly, or other utilization of some or all of the modules or functions or components that are described herein, even if they are discussed in different locations or different chapters of the above discussion, or even if they are shown across different drawings or multiple drawings.

[0267] While certain features of some embodiments have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. Accordingly, the claims are intended to cover all such modifications, substitutions, changes, and equivalents.

Claims

CLAIMS1. A computerized method comprising:generating a combined inter-institution fraud-relatedness risk-score for an inspected transaction in which a first party of a first bank is transferring funds to a second party of a second bank; by performing:(a) receiving from the first bank a first set of fraud-related signals, that are generated based on information that the first bank has about the first party and about the inspected transaction; (b) receiving from the second bank a second set of fraud-related signals, that are generated based on information that the second bank has about the second party and about the inspected transaction;(c) generating the combined inter-institution fraud-relatedness risk-score, based on an analysis that takes into account both: (cl) the first set of fraud-related signals that were generated by the first bank based on information that the first bank has about the first party and about the inspected transaction, and (c2) the second set of fraud-related signals that were generated by the second bank based on information that the second bank has about the second party and about the inspected transaction;(d) providing the combined inter-institution fraud-relatedness risk-score to at least one of: the first bank, the second bank; and if the combined inter-institution fraud-relatedness riskscore is greater than a pre-defined threshold value, then: triggering one or more pre-defined fraud mitigation operations.

2. The computerized method of claim 1,wherein the first set of fraud-related signals are generated exclusively based on information that the first bank has about the first party and about the inspected transaction; wherein the second set of fraud-related signals are generated exclusively based on information that the second bank has about the second party and about the inspected transaction.

3. The computerized method of claim 1,wherein the first set of fraud-related signals are generated exclusively based on information that the first bank has about the first party and about the inspected transaction; wherein the second set of fraud-related signals are generated based on information that is obtained from a trusted server that is external to the first bank and is external to the second bank, that indicates that another payment transaction was attempted towards said second party.

4. The computerized method of claim 1,wherein the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a proxy server to submit the inspected transaction.

5. The computerized method of claim 1,wherein the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a Virtual Private Network (VPN) to submit the inspected transaction.

6. The computerized method of claim 1,wherein the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a Virtual Machine (VM) to submit the inspected transaction.

7. The computerized method of claim 1,wherein the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on an analysis that takes into account an automatic detection that the first party is utilizing a Remote Access module to submit the inspected transaction.

8. The computerized method of claim 1,wherein the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on an analysis that takes into account a data-entry rhythm or a data-entry cadence that characterizes data-entry by the first party while it entered data of the inspected transaction through an interface of the first bank.

9. The computerized method of claim 1,wherein the first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on an analysis that takes into account data from a hardware unit of an electronic device of the first party while it entered data of the inspected transaction through an interface of the first bank; wherein said hardware component is at least one of: an accelerometer of the electronic device, a gyroscope of the electronic device, a compass unit of the electronic device, a device orientation sensor of the electronic device.

10. The computerized method of claim 1,wherein first set of fraud-related signals that are generated based on information that the first bank has about the first party and about the inspected transaction,is generated based on a data-entry analysis process, that analyzes data-entry interactions of the first party through an interface of the first bank, and that determines that said data-entry interactions of the first party are more likely to be associated with operations performed by an automated script than with operations performed by a human user.

11. The computerized method of claim 1 ,wherein the second set of fraud-related signals that are generated based on information that the second bank has about the second party and about the inspected transaction,is generated based on an analysis that takes into account an automatic detection that the second party has utilized at least one of:a Proxy Server to access the second bank,a Virtual Private Network (VPN) to access the second bank,a Virtual Machine (VM) to access the second bank,a Virtual Machine (VM) to access the second bank,a Remote Access module to access the second bank.

12. The computerized method of claim 1,wherein the second set of fraud-related signals that are generated based on information that the second bank has about the second party and about the inspected transaction,is generated based on an analysis that takes into account a data-entry rhythm or a data-entry cadence that characterizes data-entry by the first party while it entered data of the inspected transaction through an interface of the first bank.

13. The computerized method of claim 1,wherein the second set of fraud-related signals that are generated based on information that the second bank has about the second party and about the inspected transaction,is generated based on a data-entry analysis process, that analyzes data-entry interactions of the second party through an interface of the second bank, and that determines that said data-entry interactions of the second party are more likely to be associated with operations performed by an automated script than with operations performed by a human user.

14. The computerized method of claim 1,wherein the combined inter-institution fraud-relatedness risk-score is generated for the inspected transaction by further taking into account a signal, obtained from a trusted server, indicating that at least one of: the first party, the second party,had previously been involved in another banking transaction that had already been estimated to be one of: a money laundering related transaction, a terror funding related transaction, a transaction involving a mule bank account.

15. The computerized method of claim 1,wherein the combined inter-institution fraud-relatedness risk-score is generated for the inspected transaction by further taking into account a signal indicating that at least one of: the first party, the second party,is estimated to be performing banking operations that are dictated by an attacker performing a Vishing attack in accordance with an attack playbook.

16. The computerized method of claim 1,wherein the combined inter-institution fraud-relatedness risk-score is generated in real time or in near-real-time, immediately upon submission of data of the inspected transaction, based on real time analysis of fraud signals.

17. The computerized method of claim 1, wherein the first set and the second set are timestamped, versioned, and signed by their originating banks to authenticate provenance and freshness.

18. The computerized method of claim 1, wherein each bank transmits, instead of an account number, a cryptographic hash of its party identifier, preventing direct reconstruction of party identity across institutions.

19. The computerized method of claim 1, wherein hashed party identifiers are produced using institution- specific keys via HMAC, enabling consistent joining while limiting crossbank linkage outside authorized workflows.

20. The computerized method of claim 1, further comprising rotating salts or keys for generating said hashed identifiers on a periodic schedule, with invalidation of stale hashes after rotation completes.

21. The computerized method of claim 1, wherein the combined inter-institution fraud-relatedness risk-score is computed inside a hardware-backed secure enclave that enforces encrypted memory and remote attestation before execution.

22. The computerized method of claim 1 , further comprising encrypting the first and second sets in transit and at rest using mutually authenticated transport and field-level encryption for sensitive attributes.

23. The computerized method of claim 1, wherein generating the first set includes device fingerprint features, login telemetry, and session velocity for the first party related to the inspected transaction.

24. The computerized method of claim 1, wherein generating the second set includes merchant profile features, beneficiary account tenure, and recent chargeback indicators associated with the second party.

25. The computerized method of claim 1 , wherein the analysis applies graph-based features that consider historical interactions between inter-institutional accounts and inter-party devices.

26. The computerized method of claim 1, further comprising calibrating or modifying the combined inter-institution fraud-relatedness risk-score in accordance with institution-specific acceptance policies.

27. The computerized method of claim 1, wherein the pre-defined threshold value is dynamically selected based on transaction channel, amount bands, jurisdiction, and model version performance characteristics.

28. The computerized method of claim 1, further comprising: automatically generating at least one of: (i) an explanation vector attributing fractional contributions to features originating from the first bank and / or from the second bank; (ii) a group of data-points that explain one or more risk factors that contributed to the generated risk-score.

29. The computerized method of claim 1, wherein triggering the fraud mitigation operations comprises step-up authentication, temporary hold placement, and message delivery to designated operational response queues.

30. The computerized method of claim 1, wherein differential privacy noise is applied to aggregate analytics derived from the first and second sets, preserving utility for monitoring without reidentification.

31. The computerized method of claim 1, wherein entity resolution across institutions uses blinded token-based joins that require dual consent flags before linkage, recorded in a shared governance registry.

32. The computerized method of claim 1, further comprising monitoring for data drift by comparing feature distributions from each institution against baselines, triggering retraining workflows upon deviations.

33. The computerized method of claim 1, wherein the analysis includes constraints comparing first party origination location with second party receiving context to detect improbable travel patterns.

34. The computerized method of claim 1 , further comprising generating and using overlays that standardize names using transliteration rules prior to matching against domestic and international watchlists.

35. The computerized method of claim 1, wherein model training occurs using federated learning that keeps raw records within each bank while sharing gradients or parameters under privacy controls.

36. The computerized method of claim 1, further comprising maintaining model version lineage, with rollback to a previously validated model if post-deployment monitoring exceeds predefined error tolerances.

37. The computerized method of claim 1, comprising: rejecting scoring requests containing malformed timestamps, unsigned payloads, or mismatched schema versions; and recording rejection reasons for diagnostics.

38. The computerized method of claim 1, further comprising: providing replay protection using nonces or sequence counters so previously observed messages cannot be reused to influence scoring outcomes.

39. The computerized method of claim 1, wherein jurisdictional routing ensures features used in the analysis comply with regional data localization and sectoral rules before participation.

40. The computerized method of claim 1 , further comprising: enforcing human-in-the-loop review queues that prioritize inspected transactions with near-threshold scores or conflicting signals between the two institutions.

41. The computerized method of claim 1, wherein the combined inter-institution risk score incorporates uncertainty estimates that account for missing features from either institution during computation.

42. The computerized method of claim 1, further comprising: performing pre-decision counterfactual tests comparing outcomes using only the first set, only the second set, and both sets together.

43. The computerized method of claim 1, wherein mitigation triggers include sending a standardized case package containing selected features, explanations, and metadata to both banks’ case management systems.

44. The computerized method of claim 1, wherein the combined inter-institution risk-score is generated by taking into account at least one of: (i) the age of the bank account of the first party at the first bank, (ii) the age of the bank account of the second party at the second bank.

45. The computerized method of claim 44, wherein a trusted third-party server deduces the age of a particular bank account based on having previously observed a transaction involving said particular bank account.

46. The computerized method of claim 44, wherein a trusted third-party server estimates the age of a particular bank account without receiving explicitly an account age value from any bank, and by referencing timestamped evidence of prior observed transactions that involved said particular bank account.

47. A system comprising:one or more hardware processors, that are configured to execute code;that are operably associated withone or more memory units, that are configured to store code and data;wherein the one or more hardware processors are configured to perform a process comprising:generating a combined inter-institution fraud-relatedness risk-score for an inspected transaction in which a first party of a first bank is transferring funds to a second party of a second bank; by performing:(a) receiving from the first bank a first set of fraud-related signals, that are generated based on information that the first bank has about the first party and about the inspected transaction;(b) receiving from the second bank a second set of fraud-related signals, that are generated based on information that the second bank has about the second party and about the inspected transaction;(c) generating the combined inter-institution fraud-relatedness risk-score, based on an analysis that takes into account both: (cl) the first set of fraud-related signals that were generated by the first bank based on information that the first bank has about the first party and about the inspected transaction, and (c2) the second set of fraud-related signals that were generated by the second bank based on information that the second bank has about the second party and about the inspected transaction;(d) providing the combined inter-institution fraud-relatedness risk-score to at least one of: the first bank, the second bank; and if the combined inter-institution fraud-relatedness riskscore is greater than a pre-defined threshold value, then: triggering one or more pre-defined fraud mitigation operations.

Images