1. A method of managing entities in a region (111), the method comprising: retrieving, by an entity management system (109), historical transaction data (107) related to plurality of transactions performed by each of plurality of entities (101) in the region (111) from a transaction database (105) associated with the entity management system (109); classifying, by the entity management system (109), the plurality of transactions into successful transactions and failed transactions based on the historical transaction data (107); determining, by the entity management system (109), opportunity losses, for the plurality of entities (101), from the failed transactions of the corresponding plurality of entities (101) based on the historical transaction data (107) and predetermined rules (211); estimating, by the entity management system (109), total potential transactions (213) for each of the plurality of entities (101) based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities (101); ranking, by the entity management system (109), each of the plurality of entities (101) based on the total potential transactions (213); and identifying, by the entity management system (109), one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region (111).

2. The method as claimed in claim 1, wherein the historical transaction data (107) comprises at least one of a unique identifier of each of the plurality of entities (101), date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction Response Code (RC) associated with each of the plurality of transactions.

3. The method as claimed in claim 1, wherein the predetermined rules (211) comprise conditions for determining the opportunity losses based on predetermined transaction RCs.

4. The method as claimed in claim 1, wherein determining the opportunity losses comprises: comparing a transaction RC associated with the failed transactions with predetermined transaction RCs; and classifying the failed transactions as the opportunity losses based on the comparison.

5. The method as claimed in claim 1, wherein one or more of the plurality of entities (101) with number of the total potential transactions (213) more than a threshold value are identified as the one or more potential entities.

6. The method as claimed in claim 1, wherein one or more of the plurality of entities (101) with number of the total potential transactions (213) equal to, or less than a threshold value are identified as the one or more non-potential entities.

7. The method as claimed in claim 1, wherein the one or more actions comprises at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities.

8. An entity management system (109) for managing entities in a region (111), the entity management system (109) comprising: a processor (203); and a memory (205), communicatively coupled to the processor (203), wherein the memory (205) stores processor-executable instructions, which on execution, cause the processor (203) to: retrieve historical transaction data (107) related to plurality of transactions performed by each of plurality of entities (101) in the region (111) from a transaction database (105) associated with the entity management system (109); classify the plurality of transactions into successful transactions and failed transactions based on the historical transaction data (107); determine opportunity losses for the plurality of entities (101) from the failed transactions of the corresponding plurality of entities (101) based on the historical transaction data (107) and predetermined rules (211); estimate total potential transactions (213) for each of the plurality of entities (101) based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities (101); rank each of the plurality of entities (101) based on the total potential transactions (213); and identify one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities to manage the entities in the region (111).

9. The entity management system (109) as claimed in claim 8, wherein the historical transaction data (107) comprises at least one of a unique identifier of each of the plurality of entities (101), date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction Response Code (RC) associated with each of the plurality of transactions.

10. The entity management system (109) as claimed in claim 8, wherein the predetermined rules (211) comprise conditions to determine the opportunity losses based on predetermined transaction RCs.

11. The entity management system (109) as claimed in claim 8, wherein to determine the opportunity losses, the processor (203) is configured to: compare a transaction RC associated with the failed transactions with predetermined transaction RCs; and classify the failed transactions as the opportunity losses based on the comparison.

12. The entity management system (109) as claimed in claim 8, wherein the processor (203) identifies one or more of the plurality of entities (101), with number of the total potential transactions (213) more than a threshold value, as the one or more potential entities.

13. The entity management system (109) as claimed in claim 8, wherein the processor (203) identifies one or more of the plurality of entities (101), with number of the total potential transactions (213) equal to, or less than a threshold value, as the one or more non-potential entities.

14. The entity management system (109) as claimed in claim 8, wherein the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities.

15. A method of managing entities in a region (111), the method comprising: identifying, by an entity management system (109), variation in number of customers (115), in the region (111) of each of plurality of entities (101), during a predefined time interval; determining, by the entity management system (109), transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101); estimating, by the entity management system (109), potential transaction value (215) of each of the plurality of entities (101) based on at least one of the variation in number of customers (115) and the transaction density (117) of the customers (113); ranking, by the entity management system (109), each of the plurality of entities (101) based on the potential transaction value (215); and identifying, by the entity management system (109), one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region (111).

16. The method as claimed in claim 15, wherein determining the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101) comprises: identifying one or more neighboring entities for each of the plurality of entities (101) based on distance between each of the plurality of entities (101); determining number of transactions performed by each of the one or more neighboring entities; and determining the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101) based on the number of transactions performed by each of the one or more neighboring entities.

17. The method as claimed in claim 15, wherein one or more of the plurality of entities (101) with potential transaction value (215) more than a threshold potential value are identified as the one or more potential entities.

18. The method as claimed in claim 15, wherein one or more of the plurality of entities (101) with potential transaction value (215) equal to, or less than a threshold potential value are identified as the one or more non-potential entities.

19. The method as claimed in claim 15, wherein the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities for future transactions.

20. An entity management system (109) for managing entities in a region (111), the entity management system (109) comprising: a processor (203); and a memory (205), communicatively coupled to the processor (203), wherein the memory (205) stores processor-executable instructions, which on execution, cause the processor (203) to: identify variation in number of customers (115), in the region (111) of each of plurality of entities (101), during a predefined time interval; determine transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101); estimate potential transaction value (215) of each of the plurality of entities (101) based on at least one of the variation in number of customers (115) and the transaction density (117) of the customers (113); rank each of the plurality of entities (101) based on the potential transaction value (215); and identify one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region (111).

21. The entity management system (109) as claimed in claim 20, wherein to determine the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101), the processor (203) is configured to: identify one or more neighboring entities for each of the plurality of entities (101) based on distance between each of the plurality of entities (101); determine number of transactions performed by each of the one or more neighboring entities; and determine the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101) based on the number of transactions performed by each of the one or more neighboring entities.

22. The entity management system (109) as claimed in claim 20, wherein the processor (203) identifies one or more of the plurality of entities (101), with potential transaction value (215) more than a threshold potential value, as the one or more potential entities.

23. The entity management system (109) as claimed in claim 20, wherein the processor (203) identifies one or more of the plurality of entities (101), with potential transaction value (215) equal to, or less than a threshold potential value, as the one or more non-potential entities.

24. The entity management system (109) as claimed in claim 20, wherein the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities for future transactions. , Description:TECHNICAL FIELD The present subject matter is, in general, related to entity management and more particularly, but not exclusively, to methods and systems for managing entities in a region. BACKGROUND Payment infrastructure service providers offer Point-of-Sale (PoS) related services to financial institutions such as banks, and other entities associated with the banks. Generally, the financial institutions provide PoS devices to the entities and facilitate the entities to involve in sales of goods or services to their customers in a non-cash payment environment. Further, for every transaction performed using the PoS, the financial institutions would charge the entities with a service fee, which is a source of revenue for the financial institutions. Also, since the PoS devices and related services are managed by the payment infrastructure service provides, they would charge service fee to the financial institutions. Generally, such service fee is charged on a pay-per-transaction basis. Therefore, the revenue generated by the financial institutions and the payment infrastructure service providers may be directly proportional to the number of transactions completed at the entity locations. Also, to enhance net profit and to reduce operational costs, the financial institutions often come up with beneficial offers for the entities, who perform better and who have the potential to perform more number of transactions. For doing so, the financial institutions need to continuously monitor performance of the entities, who utilize the bank's payment system, and be able to accurately identify which of the entities possess higher potential to receive beneficial offers. At the same time, it would be necessary to control attrition of the entities due to better pricing or quality of service offers provided by competing entities, acquiring entities of other banks or their designated merchant acquiring service providers. The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art. SUMMARY One or more shortcomings of the prior art may be overcome, and additional advantages may be provided through the present disclosure. Additional features and advantages may be realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure. Disclosed herein is a method for managing entities in a region. The method comprises retrieving, by an entity management system, historical transaction data related to plurality of transactions performed by each of plurality of entities in the region from a transaction database associated with the entity management system. Further, the method comprises classifying the plurality of transactions into successful transactions and failed transactions based on the historical transaction data. Upon classification, the method comprises determining opportunity losses, for the plurality of entities, from the failed transactions of the corresponding plurality of entities based on the historical transaction data and predetermined rules. Thereafter, the method comprises estimating total potential transactions for each of the plurality of entities based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities. Further, the method comprises ranking each of the plurality of entities based on the total potential transactions. Finally, the method comprises identifying one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. One or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. Further, the present disclosure relates to an entity management system for managing entities in a region. The entity management system comprises a processor and a memory. The memory is communicatively coupled to the processor and stores processor-executable instructions, which on execution, cause the processor to retrieve historical transaction data related to plurality of transactions performed by each of plurality of entities in the region from a transaction database associated with the entity management system. Further, the instructions cause the processor to classify the plurality of transactions into successful transactions and failed transactions based on the historical transaction data. Thereafter, the instructions cause the processor to determine opportunity losses for the plurality of entities from the failed transactions of the corresponding plurality of entities based on the historical transaction data and predetermined rules. Upon classifying, the instructions cause the processor to estimate total potential transactions for each of the plurality of entities based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities. Thereafter, the instructions cause the processor to rank each of the plurality of entities based on the total potential transactions. Finally, the instructions cause the processor to identify one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. The processor performs one or more actions on the one or more potential entities and the one or more non-potential entities to manage the entities in the region. Furthermore, the present disclosure is related to a method of managing entities in a region. The method comprises identifying variation in number of customers in the region of each of plurality of entities during a predefined time interval. Also, the method comprises determining transaction density of the customers in the region of each of the plurality of entities. Thereafter, the method comprises estimating potential transaction value of each of the plurality of entities based on at least one of the variation in number of customers and the transaction density of the customers. Further, the method comprises ranking each of the plurality of entities based on the potential transaction value. Finally, the method comprises identifying one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. One or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. Furthermore, the present disclosure relates to an entity management system for managing entities in a region. The entity management system comprises a processor and a memory. The memory is communicatively coupled to the processor and stores processor-executable instructions, which on execution, cause the processor to identify variation in number of customers in the region of each of plurality of entities, during a predefined time interval. Further, the instructions cause the processor to determine transaction density of the customers in the region of each of the plurality of entities. Also, the instructions cause the processor to estimate potential transaction value of each of the plurality of entities based on at least one of the variation in number of customers and the transaction density of the customers. Thereafter, the instructions cause the processor to rank each of the plurality of entities based on the potential transaction value. Finally, the instructions cause the processor to identify one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. The processor performs one or more actions on the one or more potential entities and the one or more non-potential entities for managing the entities in the region The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and regarding the accompanying figures, in which: FIG. 1A and FIG. 1B illustrate exemplary environments for managing entities in a region in accordance with some embodiments of the present disclosure; FIG. 2 shows a detailed block diagram illustrating an entity management system in accordance with some embodiments of the present disclosure; FIG. 3A and FIG. 3B show flowcharts illustrating methods for managing entities in a region in accordance with some embodiments of the present disclosure; FIG. 4A and FIG. 4B show exemplary representations of a user dashboard for performing entity management in accordance with some embodiments of the present disclosure; and FIG. 5 illustrates a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure. It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown. DETAILED DESCRIPTION In the present disclosure, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the specific forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure. The terms “comprises”, “comprising”, “includes”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method. The present disclosure relates to methods and systems for managing entities in a region. In an embodiment, the present disclosure includes identifying potential and non-potential entities among plurality of entities in a region. The identification may be performed by ranking the plurality of entities based on estimation of future potential transactions or future profitability of the plurality of entities. In an embodiment, the future potential transactions may be determined as a function of opportunity losses for the plurality of entities. The opportunity losses may be inferred from data related to failed transaction of the plurality of entities. Thus, the failed transactions serve as potential indicators to gauge the actual transaction intended to be completed by the plurality of entities. Further, the opportunity loss data may be also combined with other adjustment factors such as transaction risk score, and competitivity score for assigning ranking to the plurality of entities. In an embodiment, the future profitability of the plurality of entities may be determined as a function of at least one of rate of change in number of customers in the region of the plurality of entities and a purchase density of customers around the plurality of entities. In some embodiments, the present disclosure helps in classifying the plurality of entities in a region as potential entities and non-potential entities, thereby facilitating effective management of the plurality of entities. Also, the method of present disclosure helps institutions, such as banks, to increase net profit by providing customized schemes and targeted promotional schemes to the potential entities. In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense. FIG. 1A illustrates an exemplary environment for managing entities in a region in accordance with some embodiments of the present disclosure. The environment 100A includes a plurality of entities, namely entity 1 1011 to entity N 101N (collectively referred to as plurality of entities 101), a transaction database 105, and an entity management system 109. In an embodiment, the entity management system 109 may be a computing system such as a desktop computer, a laptop, or a smartphone, which may be configured to manage the plurality of entities 101. The plurality of entities 101 may include, without limiting to, a payment merchant, a payment transaction account holder and the like, who may perform a plurality of transactions in accordance with embodiments of the present disclosure. In an embodiment, information related to plurality of transactions performed by the plurality of entities 101 may be stored in the transaction database 105. The transaction database 105 may be a remote storage unit associated with the entity management system 109. Further, the transaction database 105 may store various information related to the entity management system 109, the plurality of entities 101 and historical transaction data 107 related to plurality of transactions performed by the plurality of entities 101. The entity management system 109 may be used by a financial institution such as bank, or other entities like a merchant aggregator, a service provider, a resource manager, and the like for managing the plurality of entities 101 associated with them. In an embodiment, the entity management system 109 may retrieve the historical transaction data 107 related to the plurality of transactions performed by each of the plurality of entities 101 from the transaction database 105. As an example, the historical transaction data 107 may include, without limiting to, at least one of a unique identifier of each of the plurality of entities 101, date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction Response Code (RC) associated with each of the plurality of transactions. In an embodiment, upon receiving the historical transaction data 107, the entity management system 109 may classify the plurality of transactions into successful transactions and failed transactions based on the historical transaction data 107. A successful transaction may be a transaction in which the intended payment is complete. A failed transaction may be a transaction in which the intended payment has not been completed due to an error at the plurality of entities 101 or customers associated with the plurality of entities 101. In an embodiment, success and/or failure of the plurality of transactions may be determined based on value of the transaction RC associated with each of the plurality of transactions. In an embodiment, upon classifying the plurality of transactions, the entity management system 109 may determine opportunity losses among the failed transactions for the plurality of entities 101 based on the historical transaction data 107 and predetermined rules. As an example, a failed transaction may be considered as an opportunity loss when the failure of transaction is caused due to an error or fault occurring at the plurality of entities 101, even when there are no faults/errors on the part of the customers of the plurality of entities 101. In an embodiment, the predetermined rules used for determining the opportunity losses may include conditions for determining the opportunity losses based on predetermined transaction RCs. Further, the opportunity losses may be determined based on comparison of the RCs associated with the failed transactions with the predetermined RCs specified in the predetermined rules. In an embodiment, after determining the opportunity losses, the entity management system 109 may estimate total potential transactions for each of the plurality of entities 101 based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities 101. In other words, the total potential transactions for each of the plurality of entities 101 may be a sum of number of successful transactions performed by each of the plurality of entities 101 and number of opportunity losses suffered by each of the plurality of entities 101. In an embodiment, upon estimating the total potential transactions, the entity management system 109 may rank each of the plurality of entities 101 based on the total potential transactions. As an example, one or more of the plurality of entities 101 whose total potential transactions are more than a threshold value may be assigned with a higher rank and identified as the one or more potential entities. Similarly, one or more of the plurality of entities 101 whose total potential transactions are less than the threshold value may be assigned with a lower rank and identified as the one or more non-potential entities. In an embodiment, the threshold value may be a user-configurable value, such as 1000 transactions per month, 1500 transactions per month and the like. Subsequently, upon identifying the one or more potential entities and the one or more non-potential entities, the entity management system 109 may perform one or more actions on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions performed on the one or more potential entities may include providing one or more beneficiary schemes to the one or more potential entities. As an example, the one or more beneficiary schemes provided to the one or more potential entities may include, without limiting to, reduction in transaction charges, increase in number of free transactions and the like. Similarly, the one or more actions for the one or more non-potential entities may include providing one or more targeted promotional schemes to the one or more non-potential entities. In an embodiment, the targeted promotional schemes may prompt and/or encourage the one or more non-potential entities to enhance total potential transactions. FIG. 1B illustrates an exemplary environment for managing entities in a region in accordance with an alternative embodiment of the present disclosure. The environment 100B indicates a region of entities 111 and the entity management system 109. The region of entities 111 may include a plurality of entities, namely entity 1 1011 to entity N 101N (collectively referred to as plurality of entities 101) and one or more customers namely customer 1 1131 to customer N 113N (collectively referred to as customers 113) associated with the plurality of entities 101. In an embodiment, the region of entities 111 may be any geographic location, including any number of the plurality of entities 101 and the customers 113. The customers 113 may include persons, involved in performing transaction with the plurality of entities 101, such as retail purchasers and buyers of products and services. The plurality of entities 101 may include, without limiting to, a payment merchant, a payment transaction account holder and the like, who may perform a plurality of transactions with the customers 113. The entity management system 109 may be a computing system such as a desktop computer, a laptop, or a smartphone, which may be configured to manage the plurality of entities 101. The entity management system 109 may be used by a financial institution such as bank, or other entities like a merchant aggregator, a service provider, a resource manager, and the like for managing the plurality of entities 101 in a selected region of the plurality of entities 101. Accordingly, in an embodiment, the entity management system 109 may identify variation in number of customers 115 in the region of each of plurality of entities 101 during a predefined time interval. The variation in number of customers 115 in the region may be analyzed to derive insights about pattern and/or movement of the customers 113 with respect to an increase or decrease in the number of customers 113 in the region of entities 111 over a time interval. As an example, the predefined time interval may be 1 month. Suppose, an entity ‘E1’ has performed transactions with 150, 300 and 500 customers during three consecutive months respectively. Suppose, another entity ‘E2’ has performed transactions with 250, 275, and 100 customers during the same consecutive months, respectively. Here, the transaction pattern of ‘E1’ indicates that, number of customers for ‘E1’ has been constantly increasing over the given time period. Whereas, the transaction pattern of ‘E2’ indicates that the number of customers for ‘E2’ has been reducing or inconsistent over the given time period. Hence, the entity ‘E1’ may be considered to have a stable, and better variation in number of customers 115 compared to the entity ‘E2’. Thus, the entity ‘E1’ may be considered as a potential entity over ‘E2’. In an embodiment, in addition to identifying the variation in number of customers 115, the entity management system 109 may determine transaction density 117 of the customers 113 in the region of entities 111. Determining the transaction density 117 of the customers 113 may include identifying one or more neighboring entities for each of the plurality of entities 101 based on distance between each of the plurality of entities 101. Subsequently, the transaction density 117 of the customers 113 may be determined based on number of transactions performed by each of the one or more neighboring entities. In an embodiment, upon determining the transaction density 117, the entity management system 109 may estimate a potential transaction value of each of the plurality of entities 101 based on the variation in number of customers 115 and/or the transaction density 117 of the customers 113. In some embodiments, the potential transaction value may also be estimated based on factors such as variation in number of transactions with increase in age of the entity and number of transactions being performed in business hours of the entity. As an example, the potential transaction value for an entity may be estimated to be high if the number of transactions is increasing with the increase in age of the entity. Similarly, the potential transaction value of the entity may be estimated to be high if the entity has performed more than a predetermined number of transactions within the business hours. In an embodiment, once the potential transaction value is estimated, the entity management system 109 may rank each of the plurality of entities 101 based on the estimated potential transaction value. As an example, one or more of the plurality of entities 101 whose potential transaction value is more than a threshold potential value may be assigned with a higher rank and identified as the one or more potential entities. Alternatively, the one or more of the plurality of entities 101 whose potential transaction value is less than the threshold potential value may be assigned with a lower rank and identified as the one or more non-potential entities. In an embodiment, the threshold potential value may be a user-configurable value. Subsequently, the entity management system 109 may perform one or more actions on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions performed on the one or more potential entities may include, without limiting to, providing one or more beneficiary schemes to the one or more potential entities. As an example, the one or more beneficiary schemes provided to the one or more potential entities may include, without limiting to, reduction in transaction charges, increase in number of non-chargeable transactions for the one or more potential entities and the like. Similarly, the one or more actions for the one or more non-potential entities may include providing customized and/or targeted promotional schemes to the one or more non-potential entities for aiding the one or more non-potential entities in performing higher number of total potential transactions. In an embodiment, the entity management system 109 may be used for managing the plurality of entities 101 using any of the methods illustrated in FIG. 1A and FIG. 1B. In some implementations, after identifying the one or more potential entities and the one or more non-potential entities, the entity management system 109 may notify such results on a display interface and/or a user dashboard associated with the entity management system 109. In an implementation, the user dashboard (as shown in FIG. 4A and FIG. 4B) may be used for selecting the region of interest, inserting user-configurable threshold values for various parameters used in the disclosure. Also, the display interface may be used for displaying classification of the plurality of entities 101 as the one or more potential entities and the one or more non-potential entities using appropriate graphical representations. FIG. 2 shows a detailed block diagram illustrating an entity management system 109 in accordance with some embodiments of the present disclosure. In an implementation, the entity management system 109 may include an I/O interface 201, a processor 203, and a memory 205. The I/O interface 201 may be configured to receive historical transaction data 107 from a transaction database 105 associated with the entity management system 109. The processor 203 may be configured to perform one or more functions of the entity management system 109 for managing entities in a region 111. The memory 205 may be communicatively coupled to the processor 203 and may store data 207. In an embodiment, the data 207 may include, without limiting to, the historical transaction data 107, variation in number of customers 115, transaction density 117, predetermined rules 211, total potential transactions 213, potential transaction value 215 and other data 217. In some embodiments, the data 207 may be stored within the memory 205 in the form of various data structures. Additionally, the data 207 may be organized using data models, such as relational or hierarchical data models. The other data 217 may include data such as threshold value of potential transactions, threshold potential value of transactions, rank assigned to each of plurality of entities 101 and other temporary data and files generated while performing various functions of the entity management system 109. In an embodiment, each of the data 207 stored in the entity management system 109 may be processed by one or more modules 209 configured in the entity management system 109. In one implementation, the one or more modules 209 may be stored as a part of the processor 203. In another implementation, the one or more modules 209 may be configured external to the processor 203 and may be communicatively coupled to the processor 203. In an embodiment, the one or more modules 209 may include, without limiting to, a retrieving module 219, a transaction classification module 221, an opportunity loss determination module 223, potential transactions estimation module 225, a ranking module 227, an entity identification module 229, a variation identification module 230, a transaction density determination module 231, a transaction value estimation module 233 and other modules 235. In an implementation, selection of the one or more modules by the entity management system 109 may be decided based on the method being implemented for managing the entities in the region. For example, if the entities are being managed in accordance with the embodiment illustrated in FIG. 1A, then the relevant modules activated by the entity management system 109 may include the retrieving module 219, the transaction classification module 221, the opportunity loss determination module 223, the potential transactions estimation module 225, potential entities identification module 229 and the ranking module 227, along with other modules 235. Alternatively, if the entities are being managed in accordance with the embodiment illustrated in FIG. 1B, then the relevant modules activated by the entity management system 109 may include the retrieving module 219, the transaction density determination module 231, the transaction value estimation module 233, the ranking module 227, and the potential entities identification module 229, along with other modules 235. As used herein, the term module may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) or a memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. In an embodiment, the other modules 235 may be used to perform various miscellaneous functionalities of the entity management system 109. It will be appreciated that the one or more modules 209 may be represented as a single module or a combination of different modules. In an embodiment, the retrieving module 219 may be used for retrieving the historical transaction data 107 related to plurality of transactions performed by each of the plurality of entities 101 in the region from a transaction database 105 associated with the entity management system 109. As an example, the historical transaction data 107 retrieved by the retrieving module 219 may include, without limiting to, at least one of a unique identifier of each of the plurality of entities 101, date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction RC associated with each of the plurality of transactions. In an embodiment, the transaction classification module 221 may be used for classifying the plurality of transactions performed by the plurality of entities 101 into successful transactions and failed transactions based on the historical transaction data 107. For example, consider a list of the plurality of transactions as shown in Table A. Transaction ID Merchant ID Date of transaction Transaction Value RC Success/Failure 1001 M101 01-01-2018 10000 00 Successful 1002 M102 01-01-2018 5000 00 Successful 1003 M103 01-01-2018 2000 L1 Failed 1004 M101 02-01-2018 100 00 Successful 1005 M103 02-01-2018 35000 O1 Failed 1006 M102 03-01-2018 1350 00 Successful 1007 M101 04-01-2018 749 L1 Failed 1008 M102 04-01-2018 15230 00 Successful 1009 M103 04-01-2018 94230 L2 Failed 1010 M101 05-01-2018 250 00 Successful 1011 M103 05-01-2018 10000 O1 Failed 1012 M102 05-01-2018 7400 55 Failed Table A: Historical transaction data Here, each of the plurality of transactions are identified with unique transaction IDs 1001 to 1012 and include other transaction data such as date of performing the plurality of transactions, value of the plurality of transactions and the RCs associated with the plurality of transactions. In an implementation, the success and/or failure of the plurality of transactions may be determined based on the RC associated with each of the plurality of transactions. For example, the plurality of transactions may be identified as the successful transactions when the RC associated with the plurality of transactions is ‘00’. Alternatively, the plurality of transactions may be identified as the failed transactions when the RC associated with the plurality of transactions is any value other than ‘00’. In Table A, the transactions identified by the transaction IDs 1001, 1002, 1004, 1006, 1008 and 1010 may be considered as the successful transactions since value of their RCs is ‘00’. Similarly, the transactions identified by the transaction IDs 1003, 1005, 1007, 1009, 1011 and 1012 may be identified as the failed transactions since value of their RCs is not ‘00’. In an embodiment, the opportunity loss determination module 223 may be used for determining opportunity losses among the failed transactions of the plurality of entities 101. The opportunity losses may be determined based on the historical transaction data 107 and the predetermined rules 211. As an example, the predetermined rules 211 may include conditions for determining the opportunity losses based on predetermined transaction RCs, as depicted in Table B below. Predetermined rules Conditions Opportunity loss Nature of transaction 1 RC = L1 YES Value limit error 2 RC = L2 YES Volume limit error 3 RC = O1 YES Technical error 4 RC = O2 YES Switch error 5 RC = 55 NO Incorrect PIN 6 RC = 00 NO Successful transaction Table B: Predetermined conditions for determining opportunity losses Table B shows a non-exhaustive set of predetermined rules 211, which are conditions that determine whether a failed transaction may be considered as the opportunity loss. In an embodiment, the opportunity losses may be identified by comparing the RCs (extracted from the historical transaction data 107) of each of the failed transactions against each of the conditions specified in Table A. As an example, if the transaction RC of the failed transaction is one of L1, L2, O1 or O2, then such a failed transaction may be considered as an opportunity loss according the predetermined rules 211 numbered 1-4 specified in Table B. On the other hand, suppose if the transaction RC of the failed transaction is 55, then such a failed transaction may not be considered as the opportunity loss, according to the predetermined rule 5 specified in Table 5. That is, a failed transaction may not be considered as an opportunity loss for the entity, if the cause of failure of transaction is due to an error/fault such as incorrect PIN entered by the customer of the entity. In an embodiment, the potential transactions estimation module 225 may be used for estimating the total potential transactions 213 for each of the plurality of entities 101 based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities 101. Initially, the historical transaction data 107 related to each of the plurality of transactions may be extracted from the transaction database 105. Thereafter, the RC associated with each of the plurality of transactions may be analyzed, as illustrated in Table A, to classify the plurality of transactions as the successful transactions and the failed transactions. If there are any failed transactions identified, then the transaction RC associated with each of the failed transactions may be extracted. Subsequently, the opportunity losses among the failed transactions may be identified by comparing the extracted transaction RCs with the transaction RCs specified in the predetermined rules 211. Finally, the total potential transactions 213 may be estimated as a sum of number of the successful transactions identified and number of the opportunity losses determined, as shown in Equation (1) below: i.e., Total potential transactions 213 = No. of successful transactions + No. of opportunity losses …. (1) In an embodiment, the ranking module 227 may be used for ranking each of the plurality of entities 101 based on the total potential transactions 213 for each of the plurality of entities 101. The ranking module 227 may assign a higher rank to one or more of the plurality of entities 101, whose number of the total potential transactions 213 is more than a threshold value. For example, the threshold value may be 100. Here, the one or more entities having more than 100 total potential transactions 213 may be assigned with a higher rank such as, ‘Rank 1’. In an embodiment, the ranking module 227 may assign a lower rank to one or more of the plurality of entities 101, whose number of the total potential transactions 213 is less than the threshold value. Here, the one or more entities having 100 or less than 100 total potential transactions 213 may be assigned with a lower rank such as, ‘Rank 0’. In an embodiment, the potential entities identification module 229 may be used for identifying the one or more potential entities and the one or more non-potential entities among the plurality of entities 101 based on the ranking. In an embodiment, one or more of the plurality of entities 101 which are assigned with a higher rank may be identified as the potential entities. Similarly, one or more of the plurality of entities 101 which are assigned with a lower rank may be identified as the non-potential entities. In an embodiment, the variation identification module 230 may be used for identifying variation in number of customers 115 in the region 111 of each of the plurality of entities 101 during a predefined time interval. Suppose, an entity ‘E1’ has performed transactions with 150 customers and 300 customers during two consecutive time intervals ‘T1’ and ‘T2’ respectively. Here, the variation in number of customers 115 for the entity ‘E1’ may be identified as the difference in number of customers for ‘E1’ during the timer intervals ‘T1’ and ‘T2’, that is 150 customers. In an embodiment, the transaction density determination module 231 may be used for determining the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101. Initially, the transaction density determination module 231 may identify one or more neighboring entities for each of the plurality of entities 101 based on distance between each of the plurality of entities 101. As an example, one or more entities which operate within a distance of 1 kilometer from each other may be considered as the one or more neighboring entities. Upon identifying the one or more neighboring entities, the transaction density determination module 231 may determine number of transactions performed by each of the one or more neighboring entities. For instance, the number of transactions performed by each of the one or more neighboring entities may be determined using the historical transaction data 107 associated with each of the one or more neighboring entities. Subsequently, the transaction density determination module 231 may determine the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101 based on the number of transactions performed by each of the one or more neighboring entities. For example, suppose M1, M2 and M3 are the neighboring entities of an entity E1. Suppose, the number of transactions performed by M1, M2 and M3 over a month be 100, 500 and 300 respectively. In this scenario, the transaction density around entity E1 may be estimated to be sum of the number of transactions performed by each of the neighboring entities M1, M2 and M3. i.e., the transaction density around E1 would be 900 transactions per month. In an embodiment, when the transaction density for an entity ‘E’ is higher, it may be decided that majority of the transactions are being performed in the proximal region of the entity ‘E’. Thus, the entity ‘E’ may be considered a potential entity for future transactions. In an embodiment, the transaction value estimation module 233 may be used for estimating the potential transaction value 215 of each of the plurality of entities 101 based on the variation in number of customers 115 and/or the transaction density 117 of the customers 113. In other words, the potential transaction value 215 may be estimated as a function of the variation in number of customers 115 and/or the transaction density 117 of the customers 113, as indicated in equations (2), (3) and (4) below: Potential transaction value = Fn (Cv) … (2); OR Potential transaction value = Fn (Td) … (3); OR Potential transaction value = Fn (Cv, Td) … (4) Wherein, ‘Cv’ is the variation in number of customers 115 in the region, which is determined as difference in number of customers 113 in the region over a predetermined time interval such as 1 month; and ‘Td’ is the transaction density 117 of the customers 113 in the region. In an embodiment, upon estimating the potential transaction value 215, each of the plurality of entities 101 may be ranked by the ranking module 227 based on the potential transaction value 215 of each of the plurality of entities 101. Further, one or more potential entities and one or more non-potential entities may be identified using the potential entities identification module 229, based on the ranking. In an embodiment, classification of the plurality of entities 101 into potential entities and non-potential entities helps in deciding which of the plurality of entities 101 would be capable of performing more number of transactions during a predetermined time interval in future. Based on this decision, a user of the entity management system 109 may perform one or more actions on the plurality of entities 101 for effectively managing the plurality of entities 101. As an example, the one or more actions performed on the plurality of entities 101 may include, without limiting to, providing one or more beneficiary schemes to the one or more potential entities, and providing one or more customized and/or targeted promotional schemes to the one or more non-potential entities. FIG. 3A and FIG. 3B show flowcharts illustrating methods for managing entities in a region in accordance with some embodiments of the present disclosure. As illustrated in FIG. 3A and FIG. 3B, the methods 300A and 300B include one or more blocks illustrating alternative methods for managing entities in a region using an entity management system 109 shown in FIG. 1A and FIG. 1B. The methods 300A and 300B may be described in the general context of computer executable instructions. Generally, the computer executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types. The order in which the methods 300A and 300B are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, these methods may be implemented in any suitable hardware, software, firmware, or combination thereof. Referring to FIG. 3A, the method 300A at block 301 includes retrieving, by the entity management system 109, historical transaction data 107 related to plurality of transactions performed by each of plurality of entities 101 in the region from a transaction database 105 associated with the entity management system 109. As an example, the historical transaction data 107 may include, without limiting to, at least one of a unique identifier of each of the plurality of entities 101, date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction RC associated with each of the plurality of transactions. At block 303, the method includes classifying, by the entity management system 109, the plurality of transactions into successful transactions and failed transactions based on the historical transaction data 107. At block 305, the method includes determining, by the entity management system 109, opportunity losses, for the plurality of entities 101, from the failed transactions of the corresponding plurality of entities 101 based on the historical transaction data 107 and predetermined rules 211. In an embodiment, the predetermined rules 211 may include conditions for determining the opportunity losses based on predetermined transaction RCs. At block 307, the method includes estimating, by the entity management system 109, total potential transactions 213 for each of the plurality of entities 101 based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities 101. In an embodiment, the opportunity losses may be determined by comparing a transaction RC associated with the failed transactions with predetermined transaction RCs and then classifying the failed transactions as the opportunity losses based on the comparison. At block 309, the method includes ranking, by the entity management system 109, each of the plurality of entities 101 based on the total potential transactions 213. In an embodiment, one or more of the plurality of entities 101 with number of the total potential transactions 213 more than a threshold value may be identified as the one or more potential entities. Similarly, one or more of the plurality of entities 101 whose number of the total potential transactions 213 are equal to or less than the threshold value may be identified as the one or more non-potential entities. At block 311, the method includes identifying, by the entity management system 109, one or more potential entities and one or more non-potential entities among the plurality of entities 101 based on the ranking. In an embodiment, one or more actions may be performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions may include, without limiting to, at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more customized and/or targeted promotional schemes to the one or more non-potential entities. Now, referring to FIG. 3B, the method 300B at block 321 includes identifying, by an entity management system 109, variation in number of customers 115 in the region of each of plurality of entities 101 during a predefined time interval. As an example, the predefined time interval may be 1 week, 2 weeks and the like. At block 323, the method includes determining, by an entity management system 109, transaction density 117 of the customers 113 in the region of each of the plurality of entities 101. In an embodiment, determining the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101 may include identifying one or more neighboring entities for each of the plurality of entities 101 based on distance between each of the plurality of entities 101 and determining number of transactions performed by each of the one or more neighboring entities. Subsequently, the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101 may be determined based on the number of transactions performed by each of the one or more neighboring entities. At block 325, the method includes estimating, by an entity management system 109, potential transaction value 215 of each of the plurality of entities 101 based on the variation in number of customers 115 and/or the transaction density 117 of the customers 113. At block 327, the method includes ranking, by an entity management system 109, each of the plurality of entities 101 based on the potential transaction value 215. In an embodiment, one or more of the plurality of entities 101 with potential transaction value 215 more than a threshold potential value is identified as the one or more potential entities. Similarly, one or more of the plurality of entities 101 with potential transaction value 215 less than or equal to the threshold potential value are identified as the one or more non-potential entities. At block 329, the method includes identifying, by an entity management system 109, one or more potential entities and one or more non-potential entities among the plurality of entities 101 based on the ranking. In an embodiment, one or more actions may be performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more customized and/or targeted promotional schemes to the one or more non-potential entities. FIG. 4A and FIG. 4B show exemplary representations of a user dashboard 400 used for performing entity management in accordance with some embodiments of the present disclosure. Particularly, FIG. 4A and FIG. 4B represent an exemplary view of the display interface or a user dashboard 400 associated with the entity management system 109. For example, the user dashboard 400 may be used for receiving user’s selection of a target region of entities 111 in which the plurality of entities 101 may be managed. The user dashboard 400 may also be used for receiving various inputs and configuration parameters such as number of entities to be compared within the target region, type of the entities and details of one or more entities competing with the entities under consideration. Additionally, the user dashboard 400 may be used for presenting various graphical representations to the user upon identifying the one or more potential entities and the one or more non-potential entities within the target region. FIG. 4A is an exemplary representation of the user dashboard 400, in which two entities E1 and E2 of a region (shown as Region-1 map 401) are being compared to identify the most potential entity among E1 and E2. Here, the transaction potential of E1 and E2 may be determined by estimating the total potential transactions 213 for E1 and E2 as an aggregation of the successful transaction and opportunity losses for E1 and E2. For instance, the graphical representation of successful transactions, opportunity losses and total potential transactions 213 for E1 and E2 may be shown on the left-hand side of the user dashboard 400. As indicated by the graphical representation of successful transactions, the number of successful transactions for E1 is higher than that of E2. However, as indicated by the graphical representation of opportunity losses, the number of opportunity losses for E1 is lesser than E2. Further, the graphical representation of potential transactions, which is a resultant of aggregation of the number of successful transactions and the number of opportunity losses, indicates that the number of potential transactions for E2 is higher than that of E1. Based on the above representation, the user may decide that the entity E2 has more transaction potential than the entity E1. FIG. 4B is an exemplary representation of the user dashboard 400, which indicates the potential entities (darkened rhombus shapes in the Region-1 map 403) identified in the target region (highlighted region in the Region-1 map 403). Here, the potential entities may be identified based on transaction density 117 of the customers 113 in the target region and the variation in number of customers 115 in the target region. For example, the graphical representation of the transaction density 117 indicates that the transaction density 117 of customers 113 is higher for the one or more entities which are located closer to each other, i.e. the transaction density 117 is higher for the neighboring entities in the target region. Similarly, the graphical representation of the variation in number of customers 115 indicates that the number of customers 113 is increasing over the period of time. Thus, the user dashboard 400 indicates the potential entities and the non-potential entities in the target region and helps the user in making decision over performing one or more actions on the plurality of entities 101 in the target region. Computer System FIG. 5 illustrates a block diagram of an exemplary computer system 500 for implementing embodiments consistent with the present disclosure. In an embodiment, the computer system 500 may be an entity management system 109 shown in FIG. 1, which may be used for managing entities in a region. The computer system 500 may include a central processing unit (“CPU” or “processor”) 502. The processor 502 may comprise at least one data processor for executing program components for executing user- or system-generated business processes. A user may include a person, a financial entity such as bank, a customer, an entity and the like. The processor 502 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. The processor 502 may be disposed in communication with one or more input/output (I/O) devices (511 and 512) via I/O interface 501. The I/O interface 501 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc. Using the I/O interface 501, the computer system 500 may communicate with one or more I/O devices 511 and 512. In some implementations, the I/O interface 501 may be used to connect to a transaction database 105 for retrieving the historical transaction data 107. In some embodiments, the processor 502 may be disposed in communication with a communication network 509 via a network interface 503. The network interface 503 may communicate with the communication network 509. The network interface 503 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 503 and the communication network 509, the computer system 500 may connect to the plurality of entities 101. In an implementation, the communication network 509 can be implemented as one of the several types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 509 may either be a dedicated network or a shared network, which represents an association of several types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 509 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. In some embodiments, the processor 502 may be disposed in communication with a memory 505 (e.g., RAM 513, ROM 514, etc. as shown in FIG. 5) via a storage interface 504. The storage interface 504 may connect to memory 505 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fiber channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc. The memory 505 may store a collection of program or database components, including, without limitation, user/application interface 506, an operating system 507, a web browser 508, and the like. In some embodiments, computer system 500 may store user/application data 506, such as the data, variables, records, etc. as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle® or Sybase®. The operating system 507 may facilitate resource management and operation of the computer system 500. Examples of operating systems include, without limitation, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM® OS/2®, MICROSOFT® WINDOWS® (XP®, VISTA®/7/8, 10 etc.), APPLE® IOS®, GOOGLETM ANDROIDTM, BLACKBERRY® OS , or the like. The user interface 506 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, the user interface 506 may provide computer interaction interface elements on a display system operatively connected to the computer system 500, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, and the like. Further, Graphical User Interfaces (GUIs) may be employed, including, without limitation, APPLE® MACINTOSH® operating systems’ Aqua®, IBM® OS/2®, MICROSOFT® WINDOWS® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, JAVA®, JAVASCRIPT®, AJAX, HTML, ADOBE® FLASH®, etc.), or the like. The web browser 508 may be a hypertext viewing application. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), and the like. The web browsers 508 may utilize facilities such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), and the like. Further, the computer system 500 may implement a mail server stored program component. The mail server may utilize facilities such as ASP, ACTIVEX®, ANSI® C++/C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 500 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, and the like. Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, that is, non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media. Advantages of the embodiment of the present disclosure are illustrated herein. In an embodiment, the present disclosure helps in estimating potential transactions and future profitability for a plurality of entities in a region. In an embodiment, the method of present disclosure helps in classifying the plurality of entities in a region as potential entities and non-potential entities, thereby facilitating effective management of the plurality of entities. In an embodiment, the method of present disclosure helps financial institutions, such as banks, to increase net profit by providing beneficiary schemes to the potential entities and providing targeted promotional schemes to the non-potential entities for future transactions. The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise. The terms "including", "comprising", “having” and variations thereof mean "including but not limited to", unless expressly specified otherwise. The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise. A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be clear that more than one device/article (whether they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether they cooperate), it will be clear that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself. Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims. While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims. Referral Numerals: Reference Number Description 100A, 100B Environments 101 Entities 105 Transaction database 107 Historical transaction data 109 Entity management system 111 Region of entities 113 Customers 115 Variation in number of customers 117 Transaction density 201 I/O interface 203 Processor 205 Memory 207 Data 209 Modules 211 Predetermined rules 213 Total potential transactions 215 Potential transaction value 217 Other data 219 Retrieving module 221 Transaction classification module 223 Opportunity loss determination module 225 Potential transactions estimation module 227 Ranking module 229 Entity identification module 230 Variation identification module 231 Transaction density determination module 233 Transaction value estimation module 235 Other modules 500 Exemplary computer system 501 I/O Interface of the exemplary computer system 502 Processor of the exemplary computer system 503 Network interface 504 Storage interface 505 Memory of the exemplary computer system 506 User/Application 507 Operating system 508 Web browser 509 Communication network 511 Input devices 512 Output devices 513 RAM 514 ROM

Claims:1. A method of managing entities in a region (111), the method comprising:
retrieving, by an entity management system (109), historical transaction data (107) related to plurality of transactions performed by each of plurality of entities (101) in the region (111) from a transaction database (105) associated with the entity management system (109);
classifying, by the entity management system (109), the plurality of transactions into successful transactions and failed transactions based on the historical transaction data (107);
determining, by the entity management system (109), opportunity losses, for the plurality of entities (101), from the failed transactions of the corresponding plurality of entities (101) based on the historical transaction data (107) and predetermined rules (211);
estimating, by the entity management system (109), total potential transactions (213) for each of the plurality of entities (101) based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities (101);
ranking, by the entity management system (109), each of the plurality of entities (101) based on the total potential transactions (213); and
identifying, by the entity management system (109), one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region (111).

2. The method as claimed in claim 1, wherein the historical transaction data (107) comprises at least one of a unique identifier of each of the plurality of entities (101), date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction Response Code (RC) associated with each of the plurality of transactions.

3. The method as claimed in claim 1, wherein the predetermined rules (211) comprise conditions for determining the opportunity losses based on predetermined transaction RCs.

4. The method as claimed in claim 1, wherein determining the opportunity losses comprises:
comparing a transaction RC associated with the failed transactions with predetermined transaction RCs; and
classifying the failed transactions as the opportunity losses based on the comparison.

5. The method as claimed in claim 1, wherein one or more of the plurality of entities (101) with number of the total potential transactions (213) more than a threshold value are identified as the one or more potential entities.

6. The method as claimed in claim 1, wherein one or more of the plurality of entities (101) with number of the total potential transactions (213) equal to, or less than a threshold value are identified as the one or more non-potential entities.

7. The method as claimed in claim 1, wherein the one or more actions comprises at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities.

8. An entity management system (109) for managing entities in a region (111), the entity management system (109) comprising:
a processor (203); and
a memory (205), communicatively coupled to the processor (203), wherein the memory (205) stores processor-executable instructions, which on execution, cause the processor (203) to:
retrieve historical transaction data (107) related to plurality of transactions performed by each of plurality of entities (101) in the region (111) from a transaction database (105) associated with the entity management system (109);
classify the plurality of transactions into successful transactions and failed transactions based on the historical transaction data (107);
determine opportunity losses for the plurality of entities (101) from the failed transactions of the corresponding plurality of entities (101) based on the historical transaction data (107) and predetermined rules (211);
estimate total potential transactions (213) for each of the plurality of entities (101) based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities (101);
rank each of the plurality of entities (101) based on the total potential transactions (213); and
identify one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities to manage the entities in the region (111).

9. The entity management system (109) as claimed in claim 8, wherein the historical transaction data (107) comprises at least one of a unique identifier of each of the plurality of entities (101), date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction Response Code (RC) associated with each of the plurality of transactions.

10. The entity management system (109) as claimed in claim 8, wherein the predetermined rules (211) comprise conditions to determine the opportunity losses based on predetermined transaction RCs.

11. The entity management system (109) as claimed in claim 8, wherein to determine the opportunity losses, the processor (203) is configured to:
compare a transaction RC associated with the failed transactions with predetermined transaction RCs; and
classify the failed transactions as the opportunity losses based on the comparison.

12. The entity management system (109) as claimed in claim 8, wherein the processor (203) identifies one or more of the plurality of entities (101), with number of the total potential transactions (213) more than a threshold value, as the one or more potential entities.

13. The entity management system (109) as claimed in claim 8, wherein the processor (203) identifies one or more of the plurality of entities (101), with number of the total potential transactions (213) equal to, or less than a threshold value, as the one or more non-potential entities.

14. The entity management system (109) as claimed in claim 8, wherein the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities.

15. A method of managing entities in a region (111), the method comprising:
identifying, by an entity management system (109), variation in number of customers (115), in the region (111) of each of plurality of entities (101), during a predefined time interval;
determining, by the entity management system (109), transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101);
estimating, by the entity management system (109), potential transaction value (215) of each of the plurality of entities (101) based on at least one of the variation in number of customers (115) and the transaction density (117) of the customers (113);
ranking, by the entity management system (109), each of the plurality of entities (101) based on the potential transaction value (215); and
identifying, by the entity management system (109), one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region (111).

16. The method as claimed in claim 15, wherein determining the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101) comprises:
identifying one or more neighboring entities for each of the plurality of entities (101) based on distance between each of the plurality of entities (101);
determining number of transactions performed by each of the one or more neighboring entities; and
determining the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101) based on the number of transactions performed by each of the one or more neighboring entities.

17. The method as claimed in claim 15, wherein one or more of the plurality of entities (101) with potential transaction value (215) more than a threshold potential value are identified as the one or more potential entities.

18. The method as claimed in claim 15, wherein one or more of the plurality of entities (101) with potential transaction value (215) equal to, or less than a threshold potential value are identified as the one or more non-potential entities.

19. The method as claimed in claim 15, wherein the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities for future transactions.

20. An entity management system (109) for managing entities in a region (111), the entity management system (109) comprising:
a processor (203); and
a memory (205), communicatively coupled to the processor (203), wherein the memory (205) stores processor-executable instructions, which on execution, cause the processor (203) to:
identify variation in number of customers (115), in the region (111) of each of plurality of entities (101), during a predefined time interval;
determine transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101);
estimate potential transaction value (215) of each of the plurality of entities (101) based on at least one of the variation in number of customers (115) and the transaction density (117) of the customers (113);
rank each of the plurality of entities (101) based on the potential transaction value (215); and
identify one or more potential entities and one or more non-potential entities among the plurality of entities (101) based on the ranking, wherein one or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region (111).

21. The entity management system (109) as claimed in claim 20, wherein to determine the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101), the processor (203) is configured to:
identify one or more neighboring entities for each of the plurality of entities (101) based on distance between each of the plurality of entities (101);
determine number of transactions performed by each of the one or more neighboring entities; and
determine the transaction density (117) of the customers (113) in the region (111) of each of the plurality of entities (101) based on the number of transactions performed by each of the one or more neighboring entities.

22. The entity management system (109) as claimed in claim 20, wherein the processor (203) identifies one or more of the plurality of entities (101), with potential transaction value (215) more than a threshold potential value, as the one or more potential entities.

23. The entity management system (109) as claimed in claim 20, wherein the processor (203) identifies one or more of the plurality of entities (101), with potential transaction value (215) equal to, or less than a threshold potential value, as the one or more non-potential entities.

24. The entity management system (109) as claimed in claim 20, wherein the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more targeted promotional schemes to the one or more non-potential entities for future transactions.
, Description:TECHNICAL FIELD
The present subject matter is, in general, related to entity management and more particularly, but not exclusively, to methods and systems for managing entities in a region.

BACKGROUND
Payment infrastructure service providers offer Point-of-Sale (PoS) related services to financial institutions such as banks, and other entities associated with the banks. Generally, the financial institutions provide PoS devices to the entities and facilitate the entities to involve in sales of goods or services to their customers in a non-cash payment environment. Further, for every transaction performed using the PoS, the financial institutions would charge the entities with a service fee, which is a source of revenue for the financial institutions. Also, since the PoS devices and related services are managed by the payment infrastructure service provides, they would charge service fee to the financial institutions. Generally, such service fee is charged on a pay-per-transaction basis. Therefore, the revenue generated by the financial institutions and the payment infrastructure service providers may be directly proportional to the number of transactions completed at the entity locations.

Also, to enhance net profit and to reduce operational costs, the financial institutions often come up with beneficial offers for the entities, who perform better and who have the potential to perform more number of transactions. For doing so, the financial institutions need to continuously monitor performance of the entities, who utilize the bank's payment system, and be able to accurately identify which of the entities possess higher potential to receive beneficial offers. At the same time, it would be necessary to control attrition of the entities due to better pricing or quality of service offers provided by competing entities, acquiring entities of other banks or their designated merchant acquiring service providers.

The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

SUMMARY
One or more shortcomings of the prior art may be overcome, and additional advantages may be provided through the present disclosure. Additional features and advantages may be realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.

Disclosed herein is a method for managing entities in a region. The method comprises retrieving, by an entity management system, historical transaction data related to plurality of transactions performed by each of plurality of entities in the region from a transaction database associated with the entity management system. Further, the method comprises classifying the plurality of transactions into successful transactions and failed transactions based on the historical transaction data. Upon classification, the method comprises determining opportunity losses, for the plurality of entities, from the failed transactions of the corresponding plurality of entities based on the historical transaction data and predetermined rules. Thereafter, the method comprises estimating total potential transactions for each of the plurality of entities based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities. Further, the method comprises ranking each of the plurality of entities based on the total potential transactions. Finally, the method comprises identifying one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. One or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region.

Further, the present disclosure relates to an entity management system for managing entities in a region. The entity management system comprises a processor and a memory. The memory is communicatively coupled to the processor and stores processor-executable instructions, which on execution, cause the processor to retrieve historical transaction data related to plurality of transactions performed by each of plurality of entities in the region from a transaction database associated with the entity management system. Further, the instructions cause the processor to classify the plurality of transactions into successful transactions and failed transactions based on the historical transaction data. Thereafter, the instructions cause the processor to determine opportunity losses for the plurality of entities from the failed transactions of the corresponding plurality of entities based on the historical transaction data and predetermined rules. Upon classifying, the instructions cause the processor to estimate total potential transactions for each of the plurality of entities based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities. Thereafter, the instructions cause the processor to rank each of the plurality of entities based on the total potential transactions. Finally, the instructions cause the processor to identify one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. The processor performs one or more actions on the one or more potential entities and the one or more non-potential entities to manage the entities in the region.

Furthermore, the present disclosure is related to a method of managing entities in a region. The method comprises identifying variation in number of customers in the region of each of plurality of entities during a predefined time interval. Also, the method comprises determining transaction density of the customers in the region of each of the plurality of entities. Thereafter, the method comprises estimating potential transaction value of each of the plurality of entities based on at least one of the variation in number of customers and the transaction density of the customers. Further, the method comprises ranking each of the plurality of entities based on the potential transaction value. Finally, the method comprises identifying one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. One or more actions are performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region.

Furthermore, the present disclosure relates to an entity management system for managing entities in a region. The entity management system comprises a processor and a memory. The memory is communicatively coupled to the processor and stores processor-executable instructions, which on execution, cause the processor to identify variation in number of customers in the region of each of plurality of entities, during a predefined time interval. Further, the instructions cause the processor to determine transaction density of the customers in the region of each of the plurality of entities. Also, the instructions cause the processor to estimate potential transaction value of each of the plurality of entities based on at least one of the variation in number of customers and the transaction density of the customers. Thereafter, the instructions cause the processor to rank each of the plurality of entities based on the potential transaction value. Finally, the instructions cause the processor to identify one or more potential entities and one or more non-potential entities among the plurality of entities based on the ranking. The processor performs one or more actions on the one or more potential entities and the one or more non-potential entities for managing the entities in the region

The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and regarding the accompanying figures, in which:

FIG. 1A and FIG. 1B illustrate exemplary environments for managing entities in a region in accordance with some embodiments of the present disclosure;

FIG. 2 shows a detailed block diagram illustrating an entity management system in accordance with some embodiments of the present disclosure;

FIG. 3A and FIG. 3B show flowcharts illustrating methods for managing entities in a region in accordance with some embodiments of the present disclosure;

FIG. 4A and FIG. 4B show exemplary representations of a user dashboard for performing entity management in accordance with some embodiments of the present disclosure; and

FIG. 5 illustrates a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown.

DETAILED DESCRIPTION
In the present disclosure, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.
While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the specific forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.
The terms “comprises”, “comprising”, “includes”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.
The present disclosure relates to methods and systems for managing entities in a region. In an embodiment, the present disclosure includes identifying potential and non-potential entities among plurality of entities in a region. The identification may be performed by ranking the plurality of entities based on estimation of future potential transactions or future profitability of the plurality of entities. In an embodiment, the future potential transactions may be determined as a function of opportunity losses for the plurality of entities. The opportunity losses may be inferred from data related to failed transaction of the plurality of entities. Thus, the failed transactions serve as potential indicators to gauge the actual transaction intended to be completed by the plurality of entities. Further, the opportunity loss data may be also combined with other adjustment factors such as transaction risk score, and competitivity score for assigning ranking to the plurality of entities. In an embodiment, the future profitability of the plurality of entities may be determined as a function of at least one of rate of change in number of customers in the region of the plurality of entities and a purchase density of customers around the plurality of entities.
In some embodiments, the present disclosure helps in classifying the plurality of entities in a region as potential entities and non-potential entities, thereby facilitating effective management of the plurality of entities. Also, the method of present disclosure helps institutions, such as banks, to increase net profit by providing customized schemes and targeted promotional schemes to the potential entities.
In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

FIG. 1A illustrates an exemplary environment for managing entities in a region in accordance with some embodiments of the present disclosure.

The environment 100A includes a plurality of entities, namely entity 1 1011 to entity N 101N (collectively referred to as plurality of entities 101), a transaction database 105, and an entity management system 109. In an embodiment, the entity management system 109 may be a computing system such as a desktop computer, a laptop, or a smartphone, which may be configured to manage the plurality of entities 101. The plurality of entities 101 may include, without limiting to, a payment merchant, a payment transaction account holder and the like, who may perform a plurality of transactions in accordance with embodiments of the present disclosure. In an embodiment, information related to plurality of transactions performed by the plurality of entities 101 may be stored in the transaction database 105. The transaction database 105 may be a remote storage unit associated with the entity management system 109. Further, the transaction database 105 may store various information related to the entity management system 109, the plurality of entities 101 and historical transaction data 107 related to plurality of transactions performed by the plurality of entities 101.

The entity management system 109 may be used by a financial institution such as bank, or other entities like a merchant aggregator, a service provider, a resource manager, and the like for managing the plurality of entities 101 associated with them. In an embodiment, the entity management system 109 may retrieve the historical transaction data 107 related to the plurality of transactions performed by each of the plurality of entities 101 from the transaction database 105. As an example, the historical transaction data 107 may include, without limiting to, at least one of a unique identifier of each of the plurality of entities 101, date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction Response Code (RC) associated with each of the plurality of transactions.

In an embodiment, upon receiving the historical transaction data 107, the entity management system 109 may classify the plurality of transactions into successful transactions and failed transactions based on the historical transaction data 107. A successful transaction may be a transaction in which the intended payment is complete. A failed transaction may be a transaction in which the intended payment has not been completed due to an error at the plurality of entities 101 or customers associated with the plurality of entities 101. In an embodiment, success and/or failure of the plurality of transactions may be determined based on value of the transaction RC associated with each of the plurality of transactions.

In an embodiment, upon classifying the plurality of transactions, the entity management system 109 may determine opportunity losses among the failed transactions for the plurality of entities 101 based on the historical transaction data 107 and predetermined rules. As an example, a failed transaction may be considered as an opportunity loss when the failure of transaction is caused due to an error or fault occurring at the plurality of entities 101, even when there are no faults/errors on the part of the customers of the plurality of entities 101. In an embodiment, the predetermined rules used for determining the opportunity losses may include conditions for determining the opportunity losses based on predetermined transaction RCs. Further, the opportunity losses may be determined based on comparison of the RCs associated with the failed transactions with the predetermined RCs specified in the predetermined rules.

In an embodiment, after determining the opportunity losses, the entity management system 109 may estimate total potential transactions for each of the plurality of entities 101 based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities 101. In other words, the total potential transactions for each of the plurality of entities 101 may be a sum of number of successful transactions performed by each of the plurality of entities 101 and number of opportunity losses suffered by each of the plurality of entities 101.
In an embodiment, upon estimating the total potential transactions, the entity management system 109 may rank each of the plurality of entities 101 based on the total potential transactions. As an example, one or more of the plurality of entities 101 whose total potential transactions are more than a threshold value may be assigned with a higher rank and identified as the one or more potential entities. Similarly, one or more of the plurality of entities 101 whose total potential transactions are less than the threshold value may be assigned with a lower rank and identified as the one or more non-potential entities. In an embodiment, the threshold value may be a user-configurable value, such as 1000 transactions per month, 1500 transactions per month and the like.

Subsequently, upon identifying the one or more potential entities and the one or more non-potential entities, the entity management system 109 may perform one or more actions on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions performed on the one or more potential entities may include providing one or more beneficiary schemes to the one or more potential entities. As an example, the one or more beneficiary schemes provided to the one or more potential entities may include, without limiting to, reduction in transaction charges, increase in number of free transactions and the like. Similarly, the one or more actions for the one or more non-potential entities may include providing one or more targeted promotional schemes to the one or more non-potential entities. In an embodiment, the targeted promotional schemes may prompt and/or encourage the one or more non-potential entities to enhance total potential transactions.

FIG. 1B illustrates an exemplary environment for managing entities in a region in accordance with an alternative embodiment of the present disclosure.

The environment 100B indicates a region of entities 111 and the entity management system 109. The region of entities 111 may include a plurality of entities, namely entity 1 1011 to entity N 101N (collectively referred to as plurality of entities 101) and one or more customers namely customer 1 1131 to customer N 113N (collectively referred to as customers 113) associated with the plurality of entities 101. In an embodiment, the region of entities 111 may be any geographic location, including any number of the plurality of entities 101 and the customers 113. The customers 113 may include persons, involved in performing transaction with the plurality of entities 101, such as retail purchasers and buyers of products and services. The plurality of entities 101 may include, without limiting to, a payment merchant, a payment transaction account holder and the like, who may perform a plurality of transactions with the customers 113. The entity management system 109 may be a computing system such as a desktop computer, a laptop, or a smartphone, which may be configured to manage the plurality of entities 101.

The entity management system 109 may be used by a financial institution such as bank, or other entities like a merchant aggregator, a service provider, a resource manager, and the like for managing the plurality of entities 101 in a selected region of the plurality of entities 101. Accordingly, in an embodiment, the entity management system 109 may identify variation in number of customers 115 in the region of each of plurality of entities 101 during a predefined time interval. The variation in number of customers 115 in the region may be analyzed to derive insights about pattern and/or movement of the customers 113 with respect to an increase or decrease in the number of customers 113 in the region of entities 111 over a time interval.

As an example, the predefined time interval may be 1 month. Suppose, an entity ‘E1’ has performed transactions with 150, 300 and 500 customers during three consecutive months respectively. Suppose, another entity ‘E2’ has performed transactions with 250, 275, and 100 customers during the same consecutive months, respectively. Here, the transaction pattern of ‘E1’ indicates that, number of customers for ‘E1’ has been constantly increasing over the given time period. Whereas, the transaction pattern of ‘E2’ indicates that the number of customers for ‘E2’ has been reducing or inconsistent over the given time period. Hence, the entity ‘E1’ may be considered to have a stable, and better variation in number of customers 115 compared to the entity ‘E2’. Thus, the entity ‘E1’ may be considered as a potential entity over ‘E2’.

In an embodiment, in addition to identifying the variation in number of customers 115, the entity management system 109 may determine transaction density 117 of the customers 113 in the region of entities 111. Determining the transaction density 117 of the customers 113 may include identifying one or more neighboring entities for each of the plurality of entities 101 based on distance between each of the plurality of entities 101. Subsequently, the transaction density 117 of the customers 113 may be determined based on number of transactions performed by each of the one or more neighboring entities.

In an embodiment, upon determining the transaction density 117, the entity management system 109 may estimate a potential transaction value of each of the plurality of entities 101 based on the variation in number of customers 115 and/or the transaction density 117 of the customers 113. In some embodiments, the potential transaction value may also be estimated based on factors such as variation in number of transactions with increase in age of the entity and number of transactions being performed in business hours of the entity. As an example, the potential transaction value for an entity may be estimated to be high if the number of transactions is increasing with the increase in age of the entity. Similarly, the potential transaction value of the entity may be estimated to be high if the entity has performed more than a predetermined number of transactions within the business hours.

In an embodiment, once the potential transaction value is estimated, the entity management system 109 may rank each of the plurality of entities 101 based on the estimated potential transaction value. As an example, one or more of the plurality of entities 101 whose potential transaction value is more than a threshold potential value may be assigned with a higher rank and identified as the one or more potential entities. Alternatively, the one or more of the plurality of entities 101 whose potential transaction value is less than the threshold potential value may be assigned with a lower rank and identified as the one or more non-potential entities. In an embodiment, the threshold potential value may be a user-configurable value.

Subsequently, the entity management system 109 may perform one or more actions on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions performed on the one or more potential entities may include, without limiting to, providing one or more beneficiary schemes to the one or more potential entities. As an example, the one or more beneficiary schemes provided to the one or more potential entities may include, without limiting to, reduction in transaction charges, increase in number of non-chargeable transactions for the one or more potential entities and the like. Similarly, the one or more actions for the one or more non-potential entities may include providing customized and/or targeted promotional schemes to the one or more non-potential entities for aiding the one or more non-potential entities in performing higher number of total potential transactions.

In an embodiment, the entity management system 109 may be used for managing the plurality of entities 101 using any of the methods illustrated in FIG. 1A and FIG. 1B. In some implementations, after identifying the one or more potential entities and the one or more non-potential entities, the entity management system 109 may notify such results on a display interface and/or a user dashboard associated with the entity management system 109. In an implementation, the user dashboard (as shown in FIG. 4A and FIG. 4B) may be used for selecting the region of interest, inserting user-configurable threshold values for various parameters used in the disclosure. Also, the display interface may be used for displaying classification of the plurality of entities 101 as the one or more potential entities and the one or more non-potential entities using appropriate graphical representations.

FIG. 2 shows a detailed block diagram illustrating an entity management system 109 in accordance with some embodiments of the present disclosure.

In an implementation, the entity management system 109 may include an I/O interface 201, a processor 203, and a memory 205. The I/O interface 201 may be configured to receive historical transaction data 107 from a transaction database 105 associated with the entity management system 109. The processor 203 may be configured to perform one or more functions of the entity management system 109 for managing entities in a region 111. The memory 205 may be communicatively coupled to the processor 203 and may store data 207. In an embodiment, the data 207 may include, without limiting to, the historical transaction data 107, variation in number of customers 115, transaction density 117, predetermined rules 211, total potential transactions 213, potential transaction value 215 and other data 217.

In some embodiments, the data 207 may be stored within the memory 205 in the form of various data structures. Additionally, the data 207 may be organized using data models, such as relational or hierarchical data models. The other data 217 may include data such as threshold value of potential transactions, threshold potential value of transactions, rank assigned to each of plurality of entities 101 and other temporary data and files generated while performing various functions of the entity management system 109.

In an embodiment, each of the data 207 stored in the entity management system 109 may be processed by one or more modules 209 configured in the entity management system 109. In one implementation, the one or more modules 209 may be stored as a part of the processor 203. In another implementation, the one or more modules 209 may be configured external to the processor 203 and may be communicatively coupled to the processor 203. In an embodiment, the one or more modules 209 may include, without limiting to, a retrieving module 219, a transaction classification module 221, an opportunity loss determination module 223, potential transactions estimation module 225, a ranking module 227, an entity identification module 229, a variation identification module 230, a transaction density determination module 231, a transaction value estimation module 233 and other modules 235.

In an implementation, selection of the one or more modules by the entity management system 109 may be decided based on the method being implemented for managing the entities in the region. For example, if the entities are being managed in accordance with the embodiment illustrated in FIG. 1A, then the relevant modules activated by the entity management system 109 may include the retrieving module 219, the transaction classification module 221, the opportunity loss determination module 223, the potential transactions estimation module 225, potential entities identification module 229 and the ranking module 227, along with other modules 235. Alternatively, if the entities are being managed in accordance with the embodiment illustrated in FIG. 1B, then the relevant modules activated by the entity management system 109 may include the retrieving module 219, the transaction density determination module 231, the transaction value estimation module 233, the ranking module 227, and the potential entities identification module 229, along with other modules 235.

As used herein, the term module may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) or a memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. In an embodiment, the other modules 235 may be used to perform various miscellaneous functionalities of the entity management system 109. It will be appreciated that the one or more modules 209 may be represented as a single module or a combination of different modules.

In an embodiment, the retrieving module 219 may be used for retrieving the historical transaction data 107 related to plurality of transactions performed by each of the plurality of entities 101 in the region from a transaction database 105 associated with the entity management system 109. As an example, the historical transaction data 107 retrieved by the retrieving module 219 may include, without limiting to, at least one of a unique identifier of each of the plurality of entities 101, date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction RC associated with each of the plurality of transactions.

In an embodiment, the transaction classification module 221 may be used for classifying the plurality of transactions performed by the plurality of entities 101 into successful transactions and failed transactions based on the historical transaction data 107. For example, consider a list of the plurality of transactions as shown in Table A.

Transaction ID Merchant ID Date of transaction Transaction Value RC Success/Failure
1001 M101 01-01-2018 10000 00 Successful
1002 M102 01-01-2018 5000 00 Successful
1003 M103 01-01-2018 2000 L1 Failed
1004 M101 02-01-2018 100 00 Successful
1005 M103 02-01-2018 35000 O1 Failed
1006 M102 03-01-2018 1350 00 Successful
1007 M101 04-01-2018 749 L1 Failed
1008 M102 04-01-2018 15230 00 Successful
1009 M103 04-01-2018 94230 L2 Failed
1010 M101 05-01-2018 250 00 Successful
1011 M103 05-01-2018 10000 O1 Failed
1012 M102 05-01-2018 7400 55 Failed

Table A: Historical transaction data

Here, each of the plurality of transactions are identified with unique transaction IDs 1001 to 1012 and include other transaction data such as date of performing the plurality of transactions, value of the plurality of transactions and the RCs associated with the plurality of transactions. In an implementation, the success and/or failure of the plurality of transactions may be determined based on the RC associated with each of the plurality of transactions. For example, the plurality of transactions may be identified as the successful transactions when the RC associated with the plurality of transactions is ‘00’. Alternatively, the plurality of transactions may be identified as the failed transactions when the RC associated with the plurality of transactions is any value other than ‘00’. In Table A, the transactions identified by the transaction IDs 1001, 1002, 1004, 1006, 1008 and 1010 may be considered as the successful transactions since value of their RCs is ‘00’. Similarly, the transactions identified by the transaction IDs 1003, 1005, 1007, 1009, 1011 and 1012 may be identified as the failed transactions since value of their RCs is not ‘00’.

In an embodiment, the opportunity loss determination module 223 may be used for determining opportunity losses among the failed transactions of the plurality of entities 101. The opportunity losses may be determined based on the historical transaction data 107 and the predetermined rules 211. As an example, the predetermined rules 211 may include conditions for determining the opportunity losses based on predetermined transaction RCs, as depicted in Table B below.

Predetermined rules Conditions Opportunity loss Nature of transaction
1 RC = L1 YES Value limit error
2 RC = L2 YES Volume limit error
3 RC = O1 YES Technical error
4 RC = O2 YES Switch error
5 RC = 55 NO Incorrect PIN
6 RC = 00 NO Successful transaction

Table B: Predetermined conditions for determining opportunity losses

Table B shows a non-exhaustive set of predetermined rules 211, which are conditions that determine whether a failed transaction may be considered as the opportunity loss. In an embodiment, the opportunity losses may be identified by comparing the RCs (extracted from the historical transaction data 107) of each of the failed transactions against each of the conditions specified in Table A. As an example, if the transaction RC of the failed transaction is one of L1, L2, O1 or O2, then such a failed transaction may be considered as an opportunity loss according the predetermined rules 211 numbered 1-4 specified in Table B. On the other hand, suppose if the transaction RC of the failed transaction is 55, then such a failed transaction may not be considered as the opportunity loss, according to the predetermined rule 5 specified in Table 5. That is, a failed transaction may not be considered as an opportunity loss for the entity, if the cause of failure of transaction is due to an error/fault such as incorrect PIN entered by the customer of the entity.

In an embodiment, the potential transactions estimation module 225 may be used for estimating the total potential transactions 213 for each of the plurality of entities 101 based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities 101. Initially, the historical transaction data 107 related to each of the plurality of transactions may be extracted from the transaction database 105. Thereafter, the RC associated with each of the plurality of transactions may be analyzed, as illustrated in Table A, to classify the plurality of transactions as the successful transactions and the failed transactions. If there are any failed transactions identified, then the transaction RC associated with each of the failed transactions may be extracted. Subsequently, the opportunity losses among the failed transactions may be identified by comparing the extracted transaction RCs with the transaction RCs specified in the predetermined rules 211. Finally, the total potential transactions 213 may be estimated as a sum of number of the successful transactions identified and number of the opportunity losses determined, as shown in Equation (1) below:

i.e., Total potential transactions 213 = No. of successful transactions + No. of opportunity losses …. (1)

In an embodiment, the ranking module 227 may be used for ranking each of the plurality of entities 101 based on the total potential transactions 213 for each of the plurality of entities 101. The ranking module 227 may assign a higher rank to one or more of the plurality of entities 101, whose number of the total potential transactions 213 is more than a threshold value. For example, the threshold value may be 100. Here, the one or more entities having more than 100 total potential transactions 213 may be assigned with a higher rank such as, ‘Rank 1’. In an embodiment, the ranking module 227 may assign a lower rank to one or more of the plurality of entities 101, whose number of the total potential transactions 213 is less than the threshold value. Here, the one or more entities having 100 or less than 100 total potential transactions 213 may be assigned with a lower rank such as, ‘Rank 0’.

In an embodiment, the potential entities identification module 229 may be used for identifying the one or more potential entities and the one or more non-potential entities among the plurality of entities 101 based on the ranking. In an embodiment, one or more of the plurality of entities 101 which are assigned with a higher rank may be identified as the potential entities. Similarly, one or more of the plurality of entities 101 which are assigned with a lower rank may be identified as the non-potential entities.

In an embodiment, the variation identification module 230 may be used for identifying variation in number of customers 115 in the region 111 of each of the plurality of entities 101 during a predefined time interval. Suppose, an entity ‘E1’ has performed transactions with 150 customers and 300 customers during two consecutive time intervals ‘T1’ and ‘T2’ respectively. Here, the variation in number of customers 115 for the entity ‘E1’ may be identified as the difference in number of customers for ‘E1’ during the timer intervals ‘T1’ and ‘T2’, that is 150 customers.

In an embodiment, the transaction density determination module 231 may be used for determining the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101. Initially, the transaction density determination module 231 may identify one or more neighboring entities for each of the plurality of entities 101 based on distance between each of the plurality of entities 101. As an example, one or more entities which operate within a distance of 1 kilometer from each other may be considered as the one or more neighboring entities. Upon identifying the one or more neighboring entities, the transaction density determination module 231 may determine number of transactions performed by each of the one or more neighboring entities. For instance, the number of transactions performed by each of the one or more neighboring entities may be determined using the historical transaction data 107 associated with each of the one or more neighboring entities.

Subsequently, the transaction density determination module 231 may determine the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101 based on the number of transactions performed by each of the one or more neighboring entities. For example, suppose M1, M2 and M3 are the neighboring entities of an entity E1. Suppose, the number of transactions performed by M1, M2 and M3 over a month be 100, 500 and 300 respectively. In this scenario, the transaction density around entity E1 may be estimated to be sum of the number of transactions performed by each of the neighboring entities M1, M2 and M3. i.e., the transaction density around E1 would be 900 transactions per month. In an embodiment, when the transaction density for an entity ‘E’ is higher, it may be decided that majority of the transactions are being performed in the proximal region of the entity ‘E’. Thus, the entity ‘E’ may be considered a potential entity for future transactions.

In an embodiment, the transaction value estimation module 233 may be used for estimating the potential transaction value 215 of each of the plurality of entities 101 based on the variation in number of customers 115 and/or the transaction density 117 of the customers 113. In other words, the potential transaction value 215 may be estimated as a function of the variation in number of customers 115 and/or the transaction density 117 of the customers 113, as indicated in equations (2), (3) and (4) below:

Potential transaction value = Fn (Cv) … (2); OR
Potential transaction value = Fn (Td) … (3); OR
Potential transaction value = Fn (Cv, Td) … (4)
Wherein,
‘Cv’ is the variation in number of customers 115 in the region, which is determined as difference in number of customers 113 in the region over a predetermined time interval such as 1 month; and
‘Td’ is the transaction density 117 of the customers 113 in the region.

In an embodiment, upon estimating the potential transaction value 215, each of the plurality of entities 101 may be ranked by the ranking module 227 based on the potential transaction value 215 of each of the plurality of entities 101. Further, one or more potential entities and one or more non-potential entities may be identified using the potential entities identification module 229, based on the ranking.

In an embodiment, classification of the plurality of entities 101 into potential entities and non-potential entities helps in deciding which of the plurality of entities 101 would be capable of performing more number of transactions during a predetermined time interval in future. Based on this decision, a user of the entity management system 109 may perform one or more actions on the plurality of entities 101 for effectively managing the plurality of entities 101. As an example, the one or more actions performed on the plurality of entities 101 may include, without limiting to, providing one or more beneficiary schemes to the one or more potential entities, and providing one or more customized and/or targeted promotional schemes to the one or more non-potential entities.

FIG. 3A and FIG. 3B show flowcharts illustrating methods for managing entities in a region in accordance with some embodiments of the present disclosure.

As illustrated in FIG. 3A and FIG. 3B, the methods 300A and 300B include one or more blocks illustrating alternative methods for managing entities in a region using an entity management system 109 shown in FIG. 1A and FIG. 1B. The methods 300A and 300B may be described in the general context of computer executable instructions. Generally, the computer executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types.

The order in which the methods 300A and 300B are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, these methods may be implemented in any suitable hardware, software, firmware, or combination thereof.

Referring to FIG. 3A, the method 300A at block 301 includes retrieving, by the entity management system 109, historical transaction data 107 related to plurality of transactions performed by each of plurality of entities 101 in the region from a transaction database 105 associated with the entity management system 109. As an example, the historical transaction data 107 may include, without limiting to, at least one of a unique identifier of each of the plurality of entities 101, date of each of the plurality of transactions, a transaction identifier associated with each of the plurality of transactions, value of each of the plurality of transactions, and a transaction RC associated with each of the plurality of transactions.

At block 303, the method includes classifying, by the entity management system 109, the plurality of transactions into successful transactions and failed transactions based on the historical transaction data 107.

At block 305, the method includes determining, by the entity management system 109, opportunity losses, for the plurality of entities 101, from the failed transactions of the corresponding plurality of entities 101 based on the historical transaction data 107 and predetermined rules 211. In an embodiment, the predetermined rules 211 may include conditions for determining the opportunity losses based on predetermined transaction RCs.

At block 307, the method includes estimating, by the entity management system 109, total potential transactions 213 for each of the plurality of entities 101 based on aggregation of the successful transactions and the opportunity losses corresponding to the plurality of entities 101. In an embodiment, the opportunity losses may be determined by comparing a transaction RC associated with the failed transactions with predetermined transaction RCs and then classifying the failed transactions as the opportunity losses based on the comparison.

At block 309, the method includes ranking, by the entity management system 109, each of the plurality of entities 101 based on the total potential transactions 213. In an embodiment, one or more of the plurality of entities 101 with number of the total potential transactions 213 more than a threshold value may be identified as the one or more potential entities. Similarly, one or more of the plurality of entities 101 whose number of the total potential transactions 213 are equal to or less than the threshold value may be identified as the one or more non-potential entities.

At block 311, the method includes identifying, by the entity management system 109, one or more potential entities and one or more non-potential entities among the plurality of entities 101 based on the ranking. In an embodiment, one or more actions may be performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions may include, without limiting to, at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more customized and/or targeted promotional schemes to the one or more non-potential entities.

Now, referring to FIG. 3B, the method 300B at block 321 includes identifying, by an entity management system 109, variation in number of customers 115 in the region of each of plurality of entities 101 during a predefined time interval. As an example, the predefined time interval may be 1 week, 2 weeks and the like.

At block 323, the method includes determining, by an entity management system 109, transaction density 117 of the customers 113 in the region of each of the plurality of entities 101. In an embodiment, determining the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101 may include identifying one or more neighboring entities for each of the plurality of entities 101 based on distance between each of the plurality of entities 101 and determining number of transactions performed by each of the one or more neighboring entities. Subsequently, the transaction density 117 of the customers 113 in the region of each of the plurality of entities 101 may be determined based on the number of transactions performed by each of the one or more neighboring entities.

At block 325, the method includes estimating, by an entity management system 109, potential transaction value 215 of each of the plurality of entities 101 based on the variation in number of customers 115 and/or the transaction density 117 of the customers 113.

At block 327, the method includes ranking, by an entity management system 109, each of the plurality of entities 101 based on the potential transaction value 215. In an embodiment, one or more of the plurality of entities 101 with potential transaction value 215 more than a threshold potential value is identified as the one or more potential entities. Similarly, one or more of the plurality of entities 101 with potential transaction value 215 less than or equal to the threshold potential value are identified as the one or more non-potential entities.

At block 329, the method includes identifying, by an entity management system 109, one or more potential entities and one or more non-potential entities among the plurality of entities 101 based on the ranking. In an embodiment, one or more actions may be performed on the one or more potential entities and the one or more non-potential entities for managing the entities in the region. As an example, the one or more actions comprise at least one of providing one or more beneficiary schemes to the one or more potential entities and providing one or more customized and/or targeted promotional schemes to the one or more non-potential entities.

FIG. 4A and FIG. 4B show exemplary representations of a user dashboard 400 used for performing entity management in accordance with some embodiments of the present disclosure.

Particularly, FIG. 4A and FIG. 4B represent an exemplary view of the display interface or a user dashboard 400 associated with the entity management system 109. For example, the user dashboard 400 may be used for receiving user’s selection of a target region of entities 111 in which the plurality of entities 101 may be managed. The user dashboard 400 may also be used for receiving various inputs and configuration parameters such as number of entities to be compared within the target region, type of the entities and details of one or more entities competing with the entities under consideration. Additionally, the user dashboard 400 may be used for presenting various graphical representations to the user upon identifying the one or more potential entities and the one or more non-potential entities within the target region.

FIG. 4A is an exemplary representation of the user dashboard 400, in which two entities E1 and E2 of a region (shown as Region-1 map 401) are being compared to identify the most potential entity among E1 and E2. Here, the transaction potential of E1 and E2 may be determined by estimating the total potential transactions 213 for E1 and E2 as an aggregation of the successful transaction and opportunity losses for E1 and E2. For instance, the graphical representation of successful transactions, opportunity losses and total potential transactions 213 for E1 and E2 may be shown on the left-hand side of the user dashboard 400. As indicated by the graphical representation of successful transactions, the number of successful transactions for E1 is higher than that of E2. However, as indicated by the graphical representation of opportunity losses, the number of opportunity losses for E1 is lesser than E2. Further, the graphical representation of potential transactions, which is a resultant of aggregation of the number of successful transactions and the number of opportunity losses, indicates that the number of potential transactions for E2 is higher than that of E1. Based on the above representation, the user may decide that the entity E2 has more transaction potential than the entity E1.

FIG. 4B is an exemplary representation of the user dashboard 400, which indicates the potential entities (darkened rhombus shapes in the Region-1 map 403) identified in the target region (highlighted region in the Region-1 map 403). Here, the potential entities may be identified based on transaction density 117 of the customers 113 in the target region and the variation in number of customers 115 in the target region. For example, the graphical representation of the transaction density 117 indicates that the transaction density 117 of customers 113 is higher for the one or more entities which are located closer to each other, i.e. the transaction density 117 is higher for the neighboring entities in the target region. Similarly, the graphical representation of the variation in number of customers 115 indicates that the number of customers 113 is increasing over the period of time. Thus, the user dashboard 400 indicates the potential entities and the non-potential entities in the target region and helps the user in making decision over performing one or more actions on the plurality of entities 101 in the target region.

Computer System
FIG. 5 illustrates a block diagram of an exemplary computer system 500 for implementing embodiments consistent with the present disclosure. In an embodiment, the computer system 500 may be an entity management system 109 shown in FIG. 1, which may be used for managing entities in a region. The computer system 500 may include a central processing unit (“CPU” or “processor”) 502. The processor 502 may comprise at least one data processor for executing program components for executing user- or system-generated business processes. A user may include a person, a financial entity such as bank, a customer, an entity and the like. The processor 502 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.
The processor 502 may be disposed in communication with one or more input/output (I/O) devices (511 and 512) via I/O interface 501. The I/O interface 501 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc. Using the I/O interface 501, the computer system 500 may communicate with one or more I/O devices 511 and 512. In some implementations, the I/O interface 501 may be used to connect to a transaction database 105 for retrieving the historical transaction data 107.
In some embodiments, the processor 502 may be disposed in communication with a communication network 509 via a network interface 503. The network interface 503 may communicate with the communication network 509. The network interface 503 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 503 and the communication network 509, the computer system 500 may connect to the plurality of entities 101.
In an implementation, the communication network 509 can be implemented as one of the several types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 509 may either be a dedicated network or a shared network, which represents an association of several types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 509 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.
In some embodiments, the processor 502 may be disposed in communication with a memory 505 (e.g., RAM 513, ROM 514, etc. as shown in FIG. 5) via a storage interface 504. The storage interface 504 may connect to memory 505 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fiber channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.
The memory 505 may store a collection of program or database components, including, without limitation, user/application interface 506, an operating system 507, a web browser 508, and the like. In some embodiments, computer system 500 may store user/application data 506, such as the data, variables, records, etc. as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle® or Sybase®.
The operating system 507 may facilitate resource management and operation of the computer system 500. Examples of operating systems include, without limitation, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM® OS/2®, MICROSOFT® WINDOWS® (XP®, VISTA®/7/8, 10 etc.), APPLE® IOS®, GOOGLETM ANDROIDTM, BLACKBERRY® OS , or the like.
The user interface 506 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, the user interface 506 may provide computer interaction interface elements on a display system operatively connected to the computer system 500, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, and the like. Further, Graphical User Interfaces (GUIs) may be employed, including, without limitation, APPLE® MACINTOSH® operating systems’ Aqua®, IBM® OS/2®, MICROSOFT® WINDOWS® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, JAVA®, JAVASCRIPT®, AJAX, HTML, ADOBE® FLASH®, etc.), or the like.

The web browser 508 may be a hypertext viewing application. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), and the like. The web browsers 508 may utilize facilities such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), and the like. Further, the computer system 500 may implement a mail server stored program component. The mail server may utilize facilities such as ASP, ACTIVEX®, ANSI® C++/C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 500 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, and the like.

Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, that is, non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

Advantages of the embodiment of the present disclosure are illustrated herein.
In an embodiment, the present disclosure helps in estimating potential transactions and future profitability for a plurality of entities in a region.

In an embodiment, the method of present disclosure helps in classifying the plurality of entities in a region as potential entities and non-potential entities, thereby facilitating effective management of the plurality of entities.

In an embodiment, the method of present disclosure helps financial institutions, such as banks, to increase net profit by providing beneficiary schemes to the potential entities and providing targeted promotional schemes to the non-potential entities for future transactions.

The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise.

The terms "including", "comprising", “having” and variations thereof mean "including but not limited to", unless expressly specified otherwise.

The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.

When a single device or article is described herein, it will be clear that more than one device/article (whether they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether they cooperate), it will be clear that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.

Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Referral Numerals:

Reference Number Description
100A, 100B Environments
101 Entities
105 Transaction database
107 Historical transaction data
109 Entity management system
111 Region of entities
113 Customers
115 Variation in number of customers
117 Transaction density
201 I/O interface
203 Processor
205 Memory
207 Data
209 Modules
211 Predetermined rules
213 Total potential transactions
215 Potential transaction value
217 Other data
219 Retrieving module
221 Transaction classification module
223 Opportunity loss determination module
225 Potential transactions estimation module
227 Ranking module
229 Entity identification module
230 Variation identification module
231 Transaction density determination module
233 Transaction value estimation module
235 Other modules
500 Exemplary computer system
501 I/O Interface of the exemplary computer system
502 Processor of the exemplary computer system
503 Network interface
504 Storage interface
505 Memory of the exemplary computer system
506 User/Application
507 Operating system
508 Web browser
509 Communication network
511 Input devices
512 Output devices
513 RAM
514 ROM