DESC:BACKGROUND
Technical Field
[0001] The embodiments herein generally relate to dynamictransaction 5 routing systems,
and more particularly to a system and a method for dynamically routing a transaction in a digital
payment system to mitigate transaction failures due to system downtime and overcapacity.
Description of the Related Art
[0002] With the rapid increase in digital transactions, banking institutions face challenges
10 in maintaining seamless payment processing. Various digital payment systems, such as UPI,
IMPS, NEFT, RTGS, and AePS, operate with different infrastructures, each possessing unique
technical constraints. The lack of interoperability among these systems, coupled with finite
resource allocation for transaction processing, leads to declined transactions.
[0003] Digital transaction volumes are rapidly growing, straining the allocated physical
15 resources (e.g., server memory, CPU cores) within banks. Each payment system operates within
predefined resource limits, and sudden transaction surges may overload these systems, leading to
failed or delayed transactions. Additionally, banks schedule maintenance downtimes that
customers are often unaware of, further exacerbating transaction failures.
[0004] An existing approach to mitigating transaction failures involves mapping multiple
20 bank accounts of a customer within peer-to-peer (P2P) payment applications like Google Pay.
This method allows the application to attempt the transaction using an alternative linked bank
account if the initial transaction fails. While this provides a backup mechanism, it does not
address the root causes of transaction failures within the banking ecosystem itself.
[0005] Another approach is the introduction of additional payment channels, such as UPI
25 Lite and digital wallets, which offer pre-funded accounts for small-value transactions. While this
helps distribute transaction loads, it significantly increases implementation costs and lacks
sustainability. Instead of leveraging interoperability among existing payment channels, this
approach continuously introduces new channels, which may not be efficient in the long run.
Additionally, customers must transfer funds from their savings accounts to pre-fund wallets,
30 leading to a loss of interest income.
3
[0006] Some banks attempt to mitigate transaction failures by deploying multiple
instances of the same payment channel, effectively using them as load balancers based on
transaction type or account category. However, this requires additional physical infrastructure
and often necessitates onboarding multiple third-party service providers, adding to operational
complexity and costs. Furthermore, this solution does not utilize interoperability 5 between
existing payment channels or provide customers with real-time guidance on the best available
payment system to maximize transaction success rates.
[0007] Accordingly, there remains a need for improving the success rate of transactions
and mitigate the impact of system overcapacity or outages that result in declined transactions.
10 SUMMARY
[0008] In view of the foregoing, an embodiment herein provides a system for
dynamically routing a transaction in a digital payment system to mitigate transaction failures due
to system downtime and overcapacity. The system includes a memoryand a processor that is
communicatively connected to the memory. The processor is configured toretrieve real-time
15 performance data of one or more transaction systems when a request for transaction is received
from a user device. The transaction request includes transaction metadataassociated with theone
or more transaction systems. The performance data includesdynamically updated features
including at least one of (i) time-window-based features, (ii) event-based features, or(iii)
transaction success metrics of the one or more transaction systems.The processor is configured to
20 predict a downtime of each of the one or moretransaction systemsby executing a first trained
machine learning model thatanalyzesat least one of (i) past transaction failure rates, (ii)
transaction system responselatency, or (iii)scheduled maintenance events of each of the one or
moretransaction systems,to exclude unreliable transaction systems. The processor is configured
to determine a probability of transaction success for each of the one or more transaction
25 systemsthat are available by executing a second trained machine learning model that dynamically
updatesa weight for the features of the one or more transaction systems based on real-time
transaction outcomes. The processor is configured to selectan optimal transaction system by
prioritizing the one or more transaction systems based on the predicted transaction success
probability and determining a top ranked transaction system as the optimal transaction systemand
30 enables the user to route the transaction through the selectedoptimal transaction system. The
processor continuously updatesthe performance data of the one or more transaction system using
4
an adaptive feedback loop by (i) detecting transaction success or failure events in real-time; (ii)
applying an adaptive decay-rate technique to refine the second machine learning model that
assigns weights to the features based on recent transaction outcomes to ensure real-time system
condition reflection; and (iii) dynamically modifying the second machine learning model
parameters dynamically to enhance subsequent transaction success 5 predictions.
[0009] The system optimize transaction routing and orchestration using machine
learning, thereby improving success rates, efficiency, and customer experience. The system
dynamically selects the most optimal payment system based on real-time load conditions and
historical success rates, thereby mitigating transaction declines and enhancing banking
10 efficiency.The system enhances interoperability between payment systems to improve
transaction success rates. The system enables banks to leverage existing payment systems for
intelligent transaction re-routing, thereby reducing failure rates and ensuring seamless digital
transactions.
[0010] In some embodiments,the processor predicts the downtime of the one or
15 moretransaction systems by (i) retrieving at least one ofthe past transaction failure rates,
thetransaction system responselatency, orthe scheduled maintenance events of each of the one or
moretransaction systems; (ii) generating one or more featuresincluding time-window-based
failure patterns, event-based system performance variations, and recurring downtime schedules;
(iii) executing the first trained machine learning model that applies a logistic regression to
20 classify the one or more transaction systems as either "operational" or "down" based on real-time
transaction success metrics; and (iv) filtering out transaction systems classified as "down" from
further processing.
[0011] In some embodiments,the first machine learning model is configured to (i) apply
recursive feature elimination (RFE) to select the relevant features of the one or more transaction
25 systems for downtime prediction; (ii) determines a downtime probability score for each
transaction system using a logistic regression classifier trained on historical transaction failure
patterns; and (iii) dynamically update the weight for the features using a feedback mechanism
that incorporates recent transaction failure reports and availability status updates of each
transaction system.
30 [0012] In some embodiments,the first machine learning model integrates a variance
inflation factor (VIF) analysis to (i) identify and eliminate collinear features that
5
causeredundancy in downtime prediction; and (ii) refine downtime prediction accuracy by
prioritizing features with the highest correlation to unavailability of the translation system.
[0013] In some embodiments,the transaction system response latency is computed by (i)
measuring transaction request processing times over a predefined monitoring window; (ii)
determining a moving average of system response times across multiple historical 5 transactions;
and (iii) flagging a transaction system as "at risk" if its response time exceeds a predefined
latency threshold.
[0014] In some embodiments, the processor determinesthe probability of transaction
success by (i) extracting real-time transaction featuresincludingtransaction timestamp, system
10 load, network congestion status, and past success rates associated with the one or more
transaction systems; (ii) executing the second trained machine learning model to classify the one
or more transaction systems by assigning a probability score based on their predicted transaction
success probability; and (iii) dynamically updating the probability score of the one or more
transaction systems based on real-time transaction success and failure events.
15 [0015] In some embodiments,the second machine learning model is trained on historical
transaction success rates and transaction system response times to determine the probability of
transaction success for each available transaction system. The second machine learning model
applies a random forest classifier that (i) assigns probability weights to each transaction system
based on its past success rate, network latency, and error rate; (ii) performs feature selection
20 using recursive feature elimination (RFE) to improve classification accuracy; and (iii)
continuously updates its probability scores using an adaptive feedback loop that incorporates
recent transaction outcomes.
[0016] In some embodiments,the probability of transaction success is refined by (i)
determining a time-decay weighted average of past transaction success rates to give higher
25 importance to recent transactions; (ii) incorporating event-based features such as transaction
volume spikes and system load fluctuations; and (iii) dynamically adjusting the decision
threshold for classification based on real-time network congestion levels.
[0017] In some embodiments, the probability of transaction success is determined based
on (i) time-window-based features that track transaction success patterns over predefined
30 intervals, (ii) event-based features that analyze success trends over a specific number of recent
6
transactions; and (iii) overall system performance indicators that capture long-term reliability
trends of each transaction system.
[0018] In one aspect, a method for dynamically routing a transaction in a digital payment
system to mitigate transaction failures due to system downtime and overcapacity using a system
is provided. The methodincludes (a) retrieving, using a processor of the 5 system, real-time
performance data of one or more transaction systems when a request for transaction is received
from a user device, wherein the transaction request includes transaction metadataassociated with
theone or more transaction systems, wherein the performance data includes dynamically updated
features including at least one of (i) time-window-based features, (ii) event-based features, or(iii)
10 transaction success metrics of the plurality of transaction systems; (b) predicting, using the
processor of the system,a downtime of each of the one or more transaction systemsby executing
a first trained machine learning model thatanalyzesat least one of (i) past transaction failure rates,
(ii) transaction system responselatency, or (iii)scheduled maintenance eventsof each of the one or
more transaction systems,to exclude unreliable transaction systems; (c) determining, using the
15 processor of the system, a probability of transaction success for each of the one or more
transaction systemsthat are available by executing a second trained machine learning model that
dynamically updatesa weight for the features of the one or more transaction systems based on
real-time transaction outcomes; and (d) selecting, using the processor of the system,an optimal
transaction system by prioritizing the one or more transaction systems based on the predicted
20 transaction success probability and determining a top ranked transaction system as the optimal
transaction systemand enables the user to routethe transaction through the selectedoptimal
transaction system, wherein the processor continuously update the performance data of the one
or more transaction system using an adaptive feedback loop by (i) detecting transaction success
or failure events in real-time; (ii) applying an adaptive decay-rate technique to refine the second
25 machine learning model that assigns weights to the features based on recent transaction
outcomes to ensure real-time system condition reflection; and (iii) dynamically modifying the
second machine learning model parameters dynamically to enhance subsequent transaction
success predictions.
[0019] These and other aspects of the embodiments herein will be better appreciated and
30 understood when considered in conjunction with the following description and the accompanying
drawings. It should be understood, however, that the following descriptions, while indicating
7
preferred embodiments and numerous specific details thereof, are given by way of illustration
and not of limitation. Many changes and modifications may be made within the scope of the
embodiments herein without departing from the spirit thereof, and the embodiments herein
include all such modifications.
BRIEF DESCRIPTION 5 OF THE DRAWINGS
[0008] The embodiments herein will be better understood from the following detailed
description concerning the drawings, in which:
[0009] FIG. 1 illustrates a block diagram of a system for dynamically routing a
transaction in a digital payment system to mitigate transaction failures due to system downtime
10 and overcapacityaccording to some embodiments herein;
[0010] FIG. 2 illustrates an exploded view of the system of FIG. 1 for dynamically
routing a transaction in a digital payment system to mitigate transaction failures due to system
downtime and overcapacity according to some embodiments herein;
[0011] FIGS. 3A and 3Bare flow diagrams that illustrate a method for dynamically
15 routing a transaction in a digital payment system to mitigate transaction failures due to system
downtime and overcapacity using a systemaccording to some embodiments herein;
[0012] FIG. 4 illustrates an exemplary use case of the system of FIG. 1 for dynamically
routing a transaction in a digital payment system to mitigate transaction failures due to system
downtime and overcapacity according to some embodiments herein; and
20 [0013] FIG. 5 is a representative hardware environment for practicing the embodiments
herein with respect to FIG. 1 through 4B in accordance with the embodiments herein.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0014] The embodiments herein and the various features and advantageous details
thereof are explained more fully with reference to the non-limiting embodiments that are
25 illustrated in the accompanying drawings and detailed in the following description.Descriptions
of well-known components and processing techniques are omitted so as not unnecessarily
obscure the embodiments herein. The examples used herein are intended merely to facilitate an
understanding of ways in which the embodiments herein may be practiced and to further enable
those of skill in the art to practice the embodiments herein. Accordingly, the examples should not
30 be construed as limiting the scope of the embodiments herein.
8
[0015] The term "response time" refers to the duration it takes for the transaction system
to react or provide a response after receiving a request or initiating a transaction. This response
time encompasses various stages of the payment process, including authorization, processing,
and confirmation.
[0016] The term "machine learning model" refers tothe sequence of 5 steps involved in
building,training, evaluating, and deploying an AI model. It encompasses various stages, each
serving a specific purpose in the development lifecycle of the AI model.
[0017] The term “mobile banking” refers to the use of a mobile device, such as a
smartphone or tablet, to perform banking activities and access financial services. It allows
10 customers to manage their bank accounts, conduct transactions, and access various financial
services conveniently from their mobile devices. Mobile banking typically involves the use of a
mobile app provided by a financial institution.
[0018] The term “transaction routing” refers to the intelligent and automated process of
directing financial transactions through the most efficient and cost-effective paths within a
15 payment processing network. This technology is particularly crucial for businesses and payment
processors that handle a high volume of transactions, as it optimizes the routing based on various
factors such as cost, speed, success rate, and reliability.
[0019] The term “downtime of a transaction” refers to the period during which a
transaction cannot be processed or completed due to unavailability or malfunction of the system,
20 network, or application involved. This can occur for various reasons, including system crashes,
server maintenance, network outages, or software bugs. During downtime, users are unable to
perform transactions, which can lead to delays, financial losses, and customer dissatisfaction.
Minimizing downtime is crucial for maintaining the reliability and efficiency of transaction
processing systems.
25 [0020] As mentioned, there remains a need for a system and a method for dynamically
routing a transaction in a digital payment system to mitigate transaction failures due to system
downtime and overcapacity. Various embodiments disclosed herein provide a system and a
method for dynamically routing a transaction in a digital payment system to mitigate transaction
failures due to system downtime and overcapacity. Referring now to the drawings, and more
30 particularly to FIGS. 1 through 5, where similar reference characters denote corresponding
features consistently throughout the figures, preferred embodiments are shown.
9
[0021] FIG. 1 illustrates a block diagram of a system 100 for dynamically routing a
transaction in a digital payment system to mitigate transaction failures due to system downtime
and overcapacity according to some embodiments herein. The system 100 includes a memory102
and a processor 104 that is communicatively connected to the memory 102. The processor 104 is
configured to retrieve real-time performance data of one or more transaction 5 systems 108A-N
when a request for transaction is received from a user device 106.The one or more transaction
systems 108A-N may be, for example, NEFT, RTGS, Digital wallets, mobile payment systems
(e.g., Google pay).The user device 106 is communicatively connected to the system 100 through
a network 114. The network 114 may be a wired network or a wireless network based on at least
10 one Wi-Fi or Bluetooth. In some embodiments, the network 114 may be a combination of the
wired network and the wireless network. In some embodiments, the network 114 is the Internet.
The user device 106 without limitation, may be selected from any of a mobile phone, a Personal
Digital Assistant (PDA), a tablet, a desktop computer, a kiosk, or a laptop. The transaction may
be a payment.
15 [0022] The transaction request includes transaction metadataassociated with theone or
more transaction systems 108A-N. The transaction metadata may include one or more
transaction timestamp, a transaction ID, a transaction amount, user details, a transaction status,
and a transaction location. The performance data includesdynamically updated features including
at least one of (i) time-window-based features, (ii) event-based features, or(iii) transaction
20 success metrics of the one or more transaction systems 108A-N.The processor 104 predictsa
downtime of each of the one or moretransaction systems108A-N by executing a first trained
machine learning model 110 thatanalyzesat least one of (i) past transaction failure rates, (ii)
transaction system responselatency, or (iii)scheduled maintenance events of each of the one or
moretransaction systems 108A-N,to exclude unreliable transaction systems. The processor 104
25 determines a probability of transaction success for each of the one or more transaction
systems108A-N that are available by executing a second trained machine learning model 112
that dynamically updatesa weight for the features of the one or more transaction systems 108A-N
based on real-time transaction outcomes. The processor 104 selectsan optimal transaction system
by prioritizing the one or more transaction systems108A-N based on the predicted transaction
30 success probability and determining a top ranked transaction system as the optimal transaction
10
systemand enables the user to route the transaction through the selectedoptimal transaction
system.
[0023] The processor 104 continuously updatesthe performance data of the one or more
transaction system 108A-N using an adaptive feedback loop by (i) detecting transaction success
or failure events in real-time; (ii) applying an adaptive decay-rate technique to 5 refine the second
machine learning model 112 that assigns weights to the features based on recent transaction
outcomes to ensure real-time system condition reflection; and (iii) dynamically modifying the
second machine learning model 112 parameters dynamically to enhance subsequent transaction
success predictions.
10 [0024] The system 100 optimize transaction routing and orchestration using machine
learning, thereby improving success rates, efficiency, and customer experience. The system 100
dynamically selects the most optimal payment system based on real-time load conditions and
historical success rates, thereby mitigating transaction declines and enhancing banking
efficiency.The system 100 enhances interoperability between one or more transaction system
15 108A-N to improve transaction success rates. The system 100 enables banks to leverage existing
payment systems for intelligent transaction re-routing, thereby reducing failure rates and
ensuring seamless digital transactions.
[0025] In some embodiments, the processor 104predicts the downtime of the one or more
transaction systems 108A-N by (i) retrieving at least one ofthe past transaction failure rates,
20 thetransaction system responselatency, orthe scheduled maintenance events of each of the one or
moretransaction systems 108A-N; (ii) generating one or more featuresincluding time-windowbased
failure patterns, event-based system performance variations, and recurring downtime
schedules; (iii) executing the first trained machine learning model 110 that applies a logistic
regression to classify the one or more transaction systems 108A-Nas either "operational" or
25 "down" based on real-time transaction success metrics; and (iv) filtering out transaction systems
classified as "down" from further processing.
[0026] In some embodiments, the first machine learning model 110 is configured to (i)
apply recursive feature elimination (RFE) to select the relevant features of the one or more
transaction systems 108A-N for downtime prediction; (ii) determines a downtime probability
30 score for each transaction system 108A-N using a logistic regression classifier trained on
historical transaction failure patterns; and (iii) dynamically update the weight for the
11
featuresusing a feedback mechanism that incorporates recent transaction failure reports and
availability status updates of each transaction system 108A-N.
[0027] In some embodiments, the first machine learning model 110 integrates a variance
inflation factor (VIF) analysis to (i) identify and eliminate collinear features that cause
redundancy in downtime prediction; and (ii) refine downtime prediction accuracy 5 by prioritizing
features with the highest correlation to unavailability of the translation system.
[0028] In some embodiments, the transaction system response latency is computed by (i)
measuring transaction request processing times over a predefined monitoring window; (ii)
determining a moving average of system response times across multiple historical transactions;
10 and (iii) flagging a transaction system as "at risk" if its response time exceeds a predefined
latency threshold.
[0029] In some embodiments, the processor 104 determinesthe probability of transaction
success by (i) extracting real-time transaction features including transaction timestamp, system
load, network congestion status, and past success rates associated with the one or more
15 transaction systems 108A-N; (ii) executing the second trained machine 112 learning model to
classify the one or more transaction systems 108A-N by assigning a probability score based on
their predicted transaction success probability; and (iii) dynamically updating the probability
score of the one or more transaction systems 108A-Nbased on real-time transaction success and
failure events.
20 [0030] In some embodiments, the second machine learning model 112 is trained on
historical transaction success rates and transaction system response times to determine the
probability of transaction success for each available transaction system. The second machine
learning model 112 applies a random forest classifier that (i) assigns probability weights to each
transaction system 108A-Nbased on its past success rate, network latency, and error rate; (ii)
25 performs feature selection using recursive feature elimination (RFE) to improve classification
accuracy; and (iii) continuously updates its probability scores using an adaptive feedback loop
that incorporates recent transaction outcomes.
[0031] In some embodiments, the probability of transaction success is refined by (i)
determining a time-decay weighted average of past transaction success rates to give higher
30 importance to recent transactions; (ii) incorporating event-based features such as transaction
12
volume spikes and system load fluctuations; and (iii) dynamically adjusting the decision
threshold for classification based on real-time network congestion levels.
[0032] In some embodiments, the probability of transaction success is determined based
on (i) time-window-based features that track transaction success patterns over predefined
intervals, (ii) event-based features that analyze success trends over a specific 5 number of recent
transactions; and (iii) overall system performance indicators that capture long-term reliability
trends of each transaction system.
[0033] In some embodiments, the processor 104 initiates the transaction with the one or
more transaction systems108A-N that has the highest probability of transaction success, and if
10 the transaction fails,the processor 104routes to thetransaction system which has the second
highest probability of transaction success. In someembodiments, the processor 104displays the
probability of transaction success of each transaction systems 108A-N on a graphical user
interface, at the user device 106. The user may select an optimal transaction system based on the
probability of transaction success.
15 [0034] FIG. 2 illustrates an exploded view of the system 100 of FIG. 1 for dynamically
routing a transaction in a digital payment system to mitigate transaction failures due to system
downtime and overcapacity according to some embodiments herein. The system includes a
performance dataretrieving module 202, a downtimeprediction module 204, a
probabilitydeterminationmodule 206, an optimal transaction system selection module 210and a
20 performance dataupdating module 212.
[0035] The performance dataretrieving module 202 retrieves real-time performance data
of one or more transaction systems 108A-N when a request for transaction is received from a
user device 106. The transaction request includes transaction metadataassociated with theone or
more transaction systems 108A-N. The transaction metadata may include one or more
25 transaction timestamp, a transaction ID, a transaction amount, user details, a transaction status,
and a transaction location. The performance data includesdynamically updated features including
at least one of (i) time-window-based features, (ii) event-based features, or(iii) transaction
success metrics of the one or more transaction systems 108A-N.
[0036] The downtimeprediction module 204predictsa downtime of each of the one or
30 moretransaction systems108A-N by executing a first trained machine learning model 110
thatanalyzesat least one of (i) past transaction failure rates, (ii) transaction system
13
responselatency, or (iii)scheduled maintenance events of each of the one or moretransaction
systems 108A-N,to exclude unreliable transaction systems.In some embodiments, the
downtimeprediction module 204 predicts the downtime of the one or more transaction systems
108A-N by (i) retrieving at least one ofthe past transaction failure rates, thetransaction system
responselatency, orthe scheduled maintenance events of each of the one 5 or moretransaction
systems 108A-N, (ii) generating one or more featuresincluding time-window-based failure
patterns, event-based system performance variations, and recurring downtime schedules, (iii)
executing the first trained machine learning model 110 that applies a logistic regression to
classify the one or more transaction systems 108A-N as either "operational" or "down" based on
10 real-time transaction success metrics; and (iv) filtering out transaction systems classified as
"down" from further processing.
[0037] In some embodiments, the first machine learning model 110 integrates a variance
inflation factor (VIF) analysis to (i) identify and eliminate collinear features that cause
redundancy in downtime prediction; and (ii) refine downtime prediction accuracy by prioritizing
15 features with the highest correlation to unavailability of the translation system. In some
embodiments, the transaction system response latency is computed by (i) measuring transaction
request processing times over a predefined monitoring window; (ii) determining a moving
average of system response times across multiple historical transactions; and (iii) flagging a
transaction system as "at risk" if its response time exceeds a predefined latency threshold.
20 [0038] The probabilitydeterminationmodule 206 determines a probability of transaction
success for each of the one or more transaction systems108A-N that are available by executing a
second trained machine learning model 112 that dynamically updatesa weight for the features208
of the one or more transaction systems 108A-N based on real-time transaction outcomes. In
some embodiments, the first machine learning model 110 is configured to (i) apply recursive
25 feature elimination (RFE) to select the relevant features 208 of the one or more transaction
systems 108A-N for downtime prediction; (ii) determines a downtime probability score for each
transaction system 108A-N using a logistic regression classifier trained on historical transaction
failure patterns; and (iii) dynamically update the weight for the features208 using a feedback
mechanism that incorporates recent transaction failure reports and availability status updates of
30 each transaction system 108A-N.
14
[0039] In some embodiments, the probabilitydeterminationmodule 206 determinesthe
probability of transaction success by (i) extracting real-time transaction features including
transaction timestamp, system load, network congestion status, and past success rates associated
with the one or more transaction systems 108A-N, (ii) executing the second trained machine 112
learning model to classify the one or more transaction systems 108A-5 N by assigning a
probability score based on their predicted transaction success probability, and (iii) dynamically
updating the probability score of the one or more transaction systems 108A-N based on real-time
transaction success and failure events. In some embodiments, the second machine learning model
112 is trained on historical transaction success rates and transaction system response times to
10 determine the probability of transaction success for each available transaction system. The
second machine learning model 112 applies a random forest classifier that (i) assigns probability
weights to each transaction system 108A-N based on its past success rate, network latency, and
error rate, (ii) performs feature selection using recursive feature elimination (RFE) to improve
classification accuracy, and (iii) continuously updates its probability scores using an adaptive
15 feedback loop that incorporates recent transaction outcomes. The probability of transaction
success may be refined by (i) determining a time-decay weighted average of past transaction
success rates to give higher importance to recent transactions, (ii) incorporating event-based
features such as transaction volume spikes and system load fluctuations, and (iii) dynamically
adjusting the decision threshold for classification based on real-time network congestion levels.
20 The probability of transaction success may be determined based on (i) time-window-based
features that track transaction success patterns over predefined intervals, (ii) event-based features
that analyze success trends over a specific number of recent transactions, and (iii) overall system
performance indicators that capture long-term reliability trends of each transaction system.
[0040] The optimal transaction system selection module 210 selects an optimal
25 transaction system by prioritizing the one or more transaction systems108A-N based on the
predicted transaction success probability and determining a top ranked transaction system as the
optimal transaction systemand enables the user to route the transaction through the
selectedoptimal transaction system.
[0041] The performance dataupdating module 212 continuously updatesthe performance
30 data of the one or more transaction system 108A-N using an adaptive feedback loop 214 by (i)
detecting transaction success or failure events in real-time; (ii) applying an adaptive decay-rate
15
technique to refine the second machine learning model 112 that assigns weights to the features
208 based on recent transaction outcomes to ensure real-time system condition reflection; and
(iii) dynamically modifying the second machine learning model 112 parameters dynamically to
enhance subsequent transaction success predictions. For example, consider the feature (f1_{5s}),
a time-window-based metric that evaluates a transaction system's performance 5 over the previous
5 seconds. The significance of (f) decreases by half after every 5-second interval. In this
scenario, the 5-second window serves a dual purpose: it represents both the duration for which
the feature remains relevant and the period after which its original weight is reduced by 50%.
Suppose a feature f (selected from the selected feature set) is last updated at time t1, and the
current time is t2. The updated feature value at t2 is given by the equation f(t2)=f(t1) / 2(t2-t1)/hl10 ,
where hl represents the half-life of the feature (in seconds) for time-window-based attributes.
This formulation ensures that older data gradually loses its influence, allowing the system to
prioritize recent transactional patterns while maintaining historical relevance. By applyingthe
adaptive decay-rate technique to refine the second machine learning model 112 that assigns
15 weights to the features 208 based on recent transaction outcomes to ensure real-time system
condition reflection. This formulation ensures that older data gradually loses its influence,
allowing the model to prioritize recent transactional patterns while maintaining historical
relevance.
[0042] The primary objective of the feedback mechanism is to continuously monitor and
20 adjust the values of time-window-based, event-based, and overall attributes for a given
transaction system (k). These attributes serve as indicators of the system’s performance, where
lower values suggest suboptimal operation. The success or failure of transactions processed by
the transaction system (k) directly influences updates to these attributes through the adaptive
decay-rate techniquedescribed in the equation. For example, if the transaction system (k)
25 recovers from a series of failures and successfully processes a transaction, its attribute values are
recalibrated to reflect an increased likelihood of future success, signifying improved
performance. Conversely, if failures persist, the attribute values are adjusted downward,
signalling a decline in system reliability. Unlike traditional approaches that assign equal weight
to past and recent events, the system dynamically reduces the influence of historical data. The
30 impact of past successes and failures gradually diminishes, with their values halved at the
16
designated half-life interval. This ensures that the system prioritizes recent trends while still
retaining a tempered memory of previous performance.
[0043] The transaction system's performance is evaluated based on its success rate,
which represents the proportion of successfully processed transactions. The success rate of a
given transaction system k over a specific time interval [T1,T2]is defined as 5 the ratio of the
number of successful transactions to the total number of transactions processed by the
transaction system kwithin that period.
[0044] In some embodiments, the time-window-based featuresfor one or more
transaction systems 108A-N are determined based on the
10 outcomeofthetransactionsinthelasttsecondsthroughit(ttakesanypositive integer value. If the
current time-stamp of the transactionisT ,the correspondingtimeframeforwhichthefeaturesfor a
transaction system are determinedis [Tt, T], i.e., transactionsbetween[T t,
T]areconsideredforfeaturecalculation.
[0045] In some embodiments, at a given time-stamp (T), event- based features consider
15 the results of transactions conducted through a transactionsystem (k) over the preceding (e)
events, where (e) is any positive whole number. For instance, (f1_f2_10e) denotes the likelihood
of success based on the previous 10 consecutive transactions processed by transactionsystems
with the characteristics (f1) and (f2). This likelihood is determined by a moving average over an
(e)-length window of transactions. Should there be fewer than (e) events/transactions at a
20 specific timestamp, the likelihood of success is then determined using their cumulative average.
Initially, the event-based features for the first payment transaction are set to 1.
[0046] In some embodiments, the comprehensive features/attributes for each transaction
are determined without taking into account the distinct features of the transactionsystems (e.g.,
(f_1, f_2, f_3, \…., f_n)). These features provide insight into the overall functioning of the
25 transactionsystems. Each transaction involves the computation of time-window-based features
within a (t)-second frame and event-based attributes across (e) events, using respective
methodologies of time-decay and moving averages. For the initial transaction, the values for
these comprehensive attributes are standardized at 1.
[0047] The feature selection enhances system accuracy by ensuring that only the most
30 relevant variables are considered, eliminating redundant or insignificant data. By focusing on the
most critical features, the system becomes more reliable in tracking transaction success rates and
17
identifying system inefficiencies. This leads to improved decision-making and a more effective
payment orchestration system. Reducing the number of input features also simplifies the system,
lowering complexity and improving interpretability. The system reduces the risk of overfitting,
ensuring that predictions generalize well across various transaction scenarios. Additionally,
minimizing unnecessary features leads to a more stable and consistent performance 5 in real-world
applications.
[0048] A key advantage of feature selection is the significant reduction in computational
load, leading to faster training and processing times. By eliminating irrelevant data points, the
system can quickly analyze incoming transactions and optimize routing decisions in real-time.
10 This is particularly important in high-frequency digital payment environments where speed is
crucial for ensuring a seamless user experience. The use of Variance Inflation Factor (VIF) to
identify and remove highly correlated variables further enhances the system’s reliability.
[0049] The efficient handling of time-window-basedandevent-based features plays a
crucial role in improving prediction accuracy. The analysis revealed that shorter time spans (e.g.,
15 5 seconds, 30 seconds) and smaller event ranges (e.g., 10 events, 30 events) provide more useful
insights into payment system performance compared to extended durations. By prioritizing these
dynamic features, the model becomes more responsive to real-time fluctuations, leading to better
transaction success predictions.Optimizing feature selection leads to more efficient resource
utilization. A refined set of features requires less memory and processing power, making the AI20
driven payment orchestration system scalable across various banking infrastructures. This not
only improves transaction success rates but also reduces implementation and operational costs
for financial institutions. By leveraging Recursive Feature Elimination (RFE)andVIF-based
pruning, the system can achieve higher accuracy, better efficiency, and reduced transaction
failures in digital payment ecosystems.
25 [0050] FIGS. 3A and 3Bare flow diagrams that illustrate a method for dynamically
routing a transaction in a digital payment system to mitigate transaction failures due to system
downtime and overcapacity using a system100 according to some embodiments herein. At step
302, real-time performance data of one or more transaction systems 108A-N is retrieved using a
processor 104 of the system 100,when a request for transaction is received from a user device
30 106. The transaction request includes transaction metadataassociated with theone or more
transaction systems 108A-N.The performance data includes dynamically updated features
18
including at least one of (i) time-window-based features, (ii) event-based features, or(iii)
transaction success metrics of the plurality of transaction systems 108A-N. At step 304, a
downtime of each of the one or more transaction systems108A-N is predicted, using the
processor 104,by executing a first trained machine learning model 110 thatanalyzesat least one of
(i) past transaction failure rates, (ii) transaction system responselatency, 5 or (iii)scheduled
maintenance eventsof each of the one or more transaction systems 108A-N,to exclude unreliable
transaction systems.
[0051] At step 306, a probability of transaction success is determined, using the
processor 104,for each of the one or more transaction systems108A-N that are available by
10 executing a second trained machine learning model 112 that dynamically updatesa weight for the
features of the one or more transaction systems 108A-Nbased on real-time transaction
outcomes.At step 308, an optimal transaction systemis selected, using the processor 104,by
prioritizing the one or more transaction systems108A-Nbased on the predicted transaction
success probability and determining a top ranked transaction system as the optimal transaction
15 systemand enables the user to routethe transaction through the selectedoptimal transaction
system. The processor 104 continuously update the performance data of the one or more
transaction system 108A-Nusing an adaptive feedback loop by (i) detecting transaction success
or failure events in real-time; (ii) applying an adaptive decay-rate technique to refine the second
machine learning model 112 that assigns weights to the features based on recent transaction
20 outcomes to ensure real-time system condition reflection; and (iii) dynamically modifying the
second machine learning model 112 parameters dynamically to enhance subsequent transaction
success predictions.
[0052] FIG. 4 illustrates an exemplary use case of the system of FIG. 1 for dynamically
routing a transaction in a digital payment system to mitigate transaction failures due to system
25 downtime and overcapacity according to some embodiments herein. Whenever a user/customer
initiates a digital transaction through a bank's mobile banking app in the user device 106, the user
can select from various digital payment systemssuch as UPI, IMPS, RTGS, NEFT, AePS, and
others. The existing systems do not provide real-time success probability estimates for
transactions across these digital payment systems.With the interoperability capabilities of the
30 proposed system 100, the users will be able to view the success probability of their transaction
for each available digital payment systemswithin the mobile banking app or internet banking
19
platform.This feature empowers users/customers to make informed decisions by selecting the
digital payment systemswith the highest likelihood of success, thereby minimizing the risk of
transaction failures due to technical declines.
[0053] A representative hardware environment for practicing the embodiments herein is
depicted in FIG. 5, with reference to FIGS. 1 through 4 B. This schematic drawing 5 illustrates a
hardware configuration of a server/computer system/computing device in accordance with the
embodiments herein.The system includes at least one processing device CPU 10 that may be
interconnected via system bus 14 to various devices such as a random access memory (RAM) 12,
read-only memory (ROM) 16, and an input/output (I/O) adapter 18. The I/O adapter 18 can
10 connect to peripheral devices, such as disk units 38 and program storage devices 40 that are
readable by the system. The system can read the inventive instructions on the program storage
devices 40 and follow these instructions to execute the methodology of the embodiments herein.
The system further includes a user interface adapter 22 that connects a keyboard 28, mouse 30,
speaker 32, microphone 34, and/or other user interface devices such as a touch screen device (not
15 shown) to the bus 14 to gather user input. Additionally, a communication adapter 20 connects
the bus 14 to a data processing network 42, and a display adapter 24 connects the bus 14 to a
display device 26, which provides a graphical user interface (GUI) 36 of the output data in
accordance with the embodiments herein, or which may be embodied as an output device such as
a monitor, printer, or transmitter, for example.
20 [0054] The foregoing description of the specific embodiments will so fully reveal the
general nature of the embodiments herein that others can, by applying current knowledge, readily
modify and/or adapt for various applications such specific embodiments without departing from
the generic concept, and, therefore, such adaptations and modifications should and are intended
to be comprehended within the meaning and range of equivalents of the disclosed embodiments.
25 It is to be understood that the phraseology or terminology employed herein is for the purpose of
description and not of limitation. Therefore, while the embodiments herein have been described
in terms of preferred embodiments, those skilled in the art will recognize that the embodiments
herein can be practiced with modification within the spirit and scope. ,CLAIMS:I/We claims:
1. A system (100) for dynamically routing a transaction in a digital payment 5 system to mitigate
transaction failures due to system downtime and overcapacity, wherein the system (100)
comprises:
a memory (102);
a processor (104) communicatively connected to the memory and configured to:
10 retrieve real-time performance data of a plurality of transaction systems (108A-N)
when a request for transaction is received from a user device (106), wherein the transaction
request comprises transaction metadataassociated with the plurality of transaction systems
(108A-N), wherein the performance data comprises dynamically updated features comprising
at least one of (i) time-window-based features, (ii) event-based features, or(iii) transaction
15 success metrics of the plurality of transaction systems (108A-N);
predict a downtime of each of the plurality of transaction systems(108A-N) by
executing a first trained machine learning model (110) thatanalyzesat least one of (i) past
transaction failure rates, (ii) transaction system responselatency, or (iii)scheduled
maintenance events of each of the plurality of transaction systems (108A-N),to exclude
20 unreliable transaction systems;
characterized in that, determine a probability of transaction success for each of the
plurality of transaction systems(108A-N) that are available by executing a second trained
machine learning model (112) that dynamically updatesa weight for the features of the
plurality of transaction systems (108A-N) based on real-time transaction outcomes; and
25 selectan optimal transaction system by prioritizing the plurality of transaction
systems(108A-N) based on the predicted transaction success probability and determining a
top ranked transaction system as the optimal transaction systemand routes the transaction
through the selectedoptimal transaction system, wherein the processor (104) continuously
updatesthe performance data of the plurality of transaction systems(108A-N) using an
30 adaptive feedback loop by
detecting transaction success or failure events in real-time;
21
applying an adaptive decay-rate technique to refine the second machine learning
model (112) that assigns weights to the features based on recent transaction outcomes to
ensure real-time system condition reflection; and
dynamically modifying the second machine learning model (112) parameters
dynamically to enhance subsequenttransaction success 5 predictions.
2. The system (100) as claimed in claim 1, wherein the processor (104) predicts the downtime of
the plurality of transaction systems (108A-N) by
retrieving at least one ofthe past transaction failure rates, thetransaction system
10 responselatency, orthe scheduled maintenance events of each of the plurality of transaction
systems (108A-N);
generating one or more features comprising time-window-based failure patterns, eventbased
system performance variations, and recurring downtime schedules;
executing the first trained machine learning model (110) that applies a logistic regression
15 to classify the plurality of transaction systems (108A-N) as either "operational" or "down" based
on real-time transaction success metrics; and
filtering out transaction systems classified as "down" from further processing.
3. The system (100) as claimed in claim 2, wherein the first machine learning model (110) is
20 configured to
apply recursive feature elimination (RFE) to select the relevant features of the plurality of
transaction systems (108A-N) for downtime prediction;
determines a downtime probability score for each transaction system (108A-N) using a
logistic regression classifier trained on historical transaction failure patterns; and
25 dynamically update the weight for the features using a feedback mechanism that
incorporates recent transaction failure reports and availability status updates of each transaction
system (108A-N).
4. The system (100) as claimed in claim 1, wherein the first machine learning model (110)
30 integrates a variance inflation factor (VIF) analysis to
22
identify and eliminate collinear features that cause redundancy in downtime prediction;
and
refine downtime prediction accuracy by prioritizing features with the highest correlation
to unavailability of the translation system.
5
5. The system (100) as claimed in claim 1, wherein the transaction system response latency is
computed by
measuring transaction request processing times over a predefined monitoring window;
determining a moving average of system response times across multiple historical
10 transactions; and
flagging a transaction system as "at risk" if its response time exceeds a predefined latency
threshold.
6. The system (100) as claimed in claim 1, wherein the processor (104) determinesthe probability
15 of transaction success by
extracting real-time transaction features comprising transaction timestamp, system load,
network congestion status, and past success rates associated with the plurality of transaction
systems (108A-N);
executing the second trained machine learning model (112) to classify the plurality of
20 transaction systems (108A-N) by assigning a probability score based on their predicted
transaction success probability; and
dynamically updating the probability score of the plurality of transaction systems (108AN)
based on real-time transaction success and failure events.
25 7. The system (100) as claimed in claim 6, wherein the second machine learning model (112) is
trained on historical transaction success rates and transaction system response times to determine
the probability of transaction success for each available transaction system (108A-N), wherein
the second machine learning model (112) applies a random forest classifier that
assigns probability weights to each transaction system (108A-N) based on its past success
30 rate, network latency, and error rate;
23
performs feature selection using recursive feature elimination (RFE) to
improveclassification accuracy; and
continuously updates its probability scores using an adaptive feedback loop that
incorporates recent transaction outcomes.
5
8. The system (100) as claimed inclaim 6, wherein the probability of transaction success is
refined by
determining a time-decay weighted average of past transaction success rates to give
higher importance to recent transactions;
10 incorporating event-based features such as transaction volume spikes and system load
fluctuations; and
dynamically adjusting the decision threshold for classification based on real-time network
congestion levels.
15 9. The system (100) as claimed inclaim 1, wherein the probability of transaction success is
determined based on (i) time-window-based features that track transaction success patterns over
predefined intervals, (ii) event-based features that analyze success trends over a specific number
of recent transactions; and (iii) overall system performance indicators that capture long-term
reliability trends of each transaction system (108A-N).
20
10. A method for dynamically routing a transaction in a digital payment system to mitigate
transaction failures due to system downtime and overcapacity using a system (100), wherein the
method comprises:
retrieving, using a processor (104) of the system (100), real-time performance data of a
25 plurality of transaction systems (108A-N) when a request for transaction is received from a user
device (106), wherein the transaction request comprises transaction metadataassociated with the
plurality of transaction systems (108A-N), wherein the performance data comprises dynamically
updated features comprising at least one of (i) time-window-based features, (ii) event-based
features, or(iii) transaction success metrics of the plurality of transaction systems (108A-N);
30 predicting, using the processor (104),a downtime of each of the plurality of transaction
systems(108A-N) by executing a first trained machine learning model (110) thatanalyzesat least
24
one of (i) past transaction failure rates, (ii) transaction system responselatency, or (iii)scheduled
maintenance eventsof each of the plurality of transaction systems (108A-N),to exclude unreliable
transaction systems;
characterized in that, determining, using the processor (104), a probability of transaction
success for each of the plurality of transaction systems(108A-N) that are available 5 by executing a
second trained machine learning model (112) that dynamically updatesa weight for the features
of the plurality of transaction systems (108A-N) based on real-time transaction outcomes; and
selecting, using the processor (104),an optimal transaction system by prioritizing the plurality
of transaction systems (108A-N) based on the predicted transaction success probability and
10 determining a top ranked transaction system as the optimal transaction systemand enables the
user to routethe transaction through the selectedoptimal transaction system, wherein the
processor (104) continuously update the performance data of the plurality of transaction
systems(108A-N) using an adaptive feedback loop by
detecting transaction success or failure events in real-time;
15 applying an adaptive decay-rate technique to refine the second machine learning model
(112) that assigns weights to the features based on recent transaction outcomes to ensure realtime
system condition reflection; and
dynamically modifying the second machine learning model (112) parameters
dynamically to enhance subsequenttransaction success predictions.
Dated this March 3rd, 2025
Arjun Karthik Bala (IN/PA 1021)
Agent for Applicant
20