System and method for enhanced transaction utility

1. A method for enhanced transaction utility by utilizing one or more processors and one or more memories, the method comprising:

implementing a single data source for accessing to transaction data associated with each type of transaction related to a user account;

receiving user input data from a user computing device for requesting access to a type of transaction data related to the user account;

authenticating the user based on verifying the received user input data with pre-stored user data;

routing, in response to authenticating, to a transaction application programming interface (API) corresponding to the requested type of transaction data;

calling the transaction API via an API gateway to fetch the requested type of transaction data from the single data source; and

causing a graphical user interface (GUI) of the user computing device to display the requested type of transaction data.

2. The method according to claim 1 , further comprising:

sharing the transaction API between the single data source and a system of record that stores transaction history data associated with each type of transaction related to the user account, wherein the single data source is responsible for fulfilling “get” requests, and wherein the system of record is responsible for fulfilling “post”, or “put,” or “patch,” or “delete” requests.

3. The method according to claim 1 , wherein the single data source is a system of record for transaction level data for assisted and unassisted servicing ensuring that the user gets a consistent view of the transaction data from a single source.

4. The method according to claim 1 , wherein the single data source is configured to make the transaction data available for read access via a set of small, independently versioned, and scalable services with specific business goals.

5. The method according to claim 1 , wherein the single data source is configured to store a complete set of commonly used fields for each type of transaction, transaction data enrichment, and supplementary data.

6. The method according to claim 5 , wherein the transaction data enrichment includes one or more of the following data: cleansed counterparty name data, cleansed category data, deduced recurring indicator data, and card on file indicator data.

7. The method according to claim 5 , wherein the supplementary data includes one or more of the following data to identify a transaction: automated clearing house (ACH) payee information data and real-time payment (RTP) payee information data.

8. The method according to claim 1 , further comprising:

filtering the transaction data based on one or more of the following type of data: date range data, merchant data, payee data, category data, and amount data; and

displaying the filtered transaction data in response to received user input data associated with type of data requested.

9. The method according to claim 1 , wherein, when accessing the single data source, if no response is received within a predetermined time period, the method further comprising:

automatically requesting again to fetch the transaction data from other system of record that stores the transaction data.

10. A system for enhanced transaction utility, the system comprising:

a processor; and

one or memories operatively connected to the processor via a communication network, wherein the processor is configured to:

implement a single data source for accessing to transaction data associated with each type of transaction related to a user account;

cause a receiver to receive user input data from a user computing device for requesting access to a type of transaction data related to the user account from the single data source;

authenticate the user based on verifying the received user input data with pre-stored user data;

route, in response to authenticating, to a transaction application programming interface (API) corresponding to the requested type of transaction data;

call the transaction API via an API gateway to fetch the requested type of transaction data from the single data source; and

cause a graphical user interface (GUI) of the user computing device to display the requested type of transaction data.

11. The system according to claim 10 , wherein the processor is further configured to:

share the transaction API between the single data source and a system of record that stores transaction history data associated with each type of transaction related to the user account, wherein the single data source is responsible for fulfilling “get” requests, and wherein the system of record is responsible for fulfilling “post”, or “put,” or “patch,” or “delete” requests.

12. The system according to claim 10 , wherein the single data source is a system of record for transaction level data for assisted and unassisted servicing ensuring that the user gets a consistent view of the transaction data from a single source.

13. The system according to claim 10 , wherein the single data source is configured to make the transaction data available for read access via a set of small, independently versioned, and scalable services with specific business goals.

14. The system according to claim 10 , wherein the single data source is configured to store a complete set of commonly used fields for each type of transaction, transaction data enrichment, and supplementary data.

15. The system according to claim 14 , wherein the transaction data enrichment includes one or more of the following data: cleansed counterparty name data, cleansed category data, deduced recurring indicator data, and card on file indicator data.

16. The system according to claim 14 , wherein the supplementary data includes one or more of the following data to identify a transaction: automated clearing house (ACH) payee information data and real-time payment (RTP) payee information data.

17. The system according to claim 10 , wherein the processor is further configured to:

filter the transaction data based on one or more of the following type of data: date range data, merchant data, payee data, category data, and amount data; and

display the filtered transaction data in response to received user input data associated with type of data requested.

18. The system according to claim 10 , wherein, when accessing the single data source, if no response is received within a predetermined time period, the processor is further configured to:

automatically request again to fetch the transaction data from other system of record that stores the transaction data.

19. A non-transitory computer readable medium configured to store instructions for enhanced transaction utility, wherein when executed, the instructions cause a processor to:

implement a single data source for accessing to transaction data associated with each type of transaction related to a user account;

cause a receiver to receive user input data from a user computing device for requesting access to a type of transaction data related to the user account from the single data source;

authenticate the user based on verifying the received user input data with pre-stored user data;

route, in response to authenticating, to a transaction application programming interface (API) corresponding to the requested type of transaction data;

call the transaction API via an API gateway to fetch the requested type of transaction data from the single data source; and

cause a graphical user interface (GUI) of the user computing device to display the requested type of transaction data.

20. The non-transitory computer readable medium according to claim 19 , wherein the instructions, when executed, further cause the processor to:

filter the transaction data based on one or more of the following type of data: date range data, merchant data, payee data, category data, and amount data; and

display the filtered transaction data in response to received user input data associated with type of data requested.