SYSTEMS AND PROCESSES THAT INCREASE TRANSACTION DATA TRANSPARENCY.

Abstract

Techniques for increasing the transparency of published transaction data are described. These techniques may include one or more of the following: associating a financial account with a user's account on a transaction management platform; receiving transaction data from the financial account; categorizing the transaction data; publishing the transaction data; assigning permission levels to the user for different levels of account access and granularity of published transaction data; storing an immutable record of transaction data from which changes to the transaction data can be determined; and enabling collective intelligence about the entity, account, or transactions by logging user interaction with the published transaction data.

Description

SYSTEMS AND PROCESSES THAT INCREASE TRANSACTION DATA TRANSPARENCY Related requests This PCT application claims priority to U.S. Provisional Patent Application No. 62 / 886,808, filed on August 14, 2019, which is incorporated herein. Background of the invention Traditionally, financial transaction data has been published online at a single level of access and granularity. For example, a nonprofit organization might choose to list its financial transactions on its website, and all different types of stakeholders see the same data when they visit the site. Customizing transaction data for specific audiences requires time and expense that the nonprofit may not have. Additionally, viewers of published transaction information are typically unable to determine whether the transaction data has been altered or deleted, either accidentally or fraudulently. Publishing transaction information is of little value without a guarantee of its integrity. Furthermore, there has not traditionally been a financial social platform that enables online collaboration regarding published financial data. Furthermore, donors to charities, political campaigns, disaster relief efforts, and the like have had to wait for quarterly or annual reports to see how their donations are being spent, if that information is even available. There is a need for techniques to publish transaction data in real time or near real time along with an indication of whether the transaction data for individual transactions has been altered. There is an additional need for techniques to publish transaction data in a way that access to the granularity of transaction data can be automatically customized to levels that are based at least in part on the characteristics of the individual seeking to access the transaction data. Brief description of the drawings The detailed description is provided with reference to the accompanying figures. In the figures, the leftmost digits of a reference number identify the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical elements or characteristics. Figure 1 illustrates an exemplary operating environment in which the techniques described herein can be implemented, as described herein. Figure 2 illustrates a block diagram of selected components from one or more exemplary user devices as described herein. Figure 3 illustrates a block diagram of selected components from one or more exemplary tracker devices, as described herein. Figures 4A, 4B, 4C, 4D, and 4E are a flowchart illustrating an exemplary process for linking a financial account to a transaction management platform, as described herein. Figure 5 is a flowchart that illustrates an exemplary process for updating transaction data for a linked financial account, as described herein. Figure 6 is a flowchart that illustrates an exemplary process for categorizing and summarizing transaction data for a linked financial account, as described herein. Figure 7 is a flowchart illustrating an exemplary process for determining whether transaction data has been changed or deleted after being received from a financial institution, as described herein. Figure 8 is a flowchart that illustrates an exemplary process for providing a user interface that includes information about changes to transaction data, as described herein. Figure 9 illustrates an exemplary user interface (UI) that provides information regarding categories of transactions of an entity, as described herein. Figure 10 illustrates an exemplary Ul that provides a list of transactions and associated information for one category of the transaction categories illustrated in Figure 9, as described herein. Figure 11 illustrates an example that provides details regarding a transaction from the transaction list in Figure 10. Figure 12 illustrates a flowchart that illustrates an exemplary process for incoming data flow associated with a synchronization service (“synchronization service”). Detailed description of the invention This disclosure generally pertains to a system and / or method that facilitates and enhances the transparency of transaction data. In the examples, the system includes one or more server devices and one or more storage devices. The server device(s) may be configured to include one or more transaction management modules and one or more financial social modules that enable a transaction management platform and a financial social network. The techniques described in this document are aimed at actions that include publishing an entity's transaction data directly from a financial institution, selecting one or more audiences for the published transaction data, monitoring transaction data for changes, alerting an entity's followers and stakeholders about changes to the transaction data, certifying the integrity of the transaction data, providing increasing permissions and increasing levels of data volume and granularity to which viewers are entitled, and classifying data. MA / t / ZUZZ / UÓ 1400 transaction across multiple category hierarchies, and / or adding metadata to raw financial transaction data. As used herein, “enhanced transparency” and variations thereof may include one or more of the above actions. As used herein, “follower” may include a person or organization that has access to the published transaction data of an account and may additionally or alternatively be notified of newly published, deleted, or changed transaction data. As used herein, “financial transaction data” and “transaction data” are used interchangeably and may include one or more data elements that identify or otherwise describe information related to the transaction. In the examples, descriptions of items purchased and the amount paid for the items can be considered transaction data.Other possible parameters that may be considered as transaction data with respect to a transaction include, but are not limited to: name of the payee, seller, or business from which items were purchased; transaction location (e.g., including geocoding information); purchase date; purchase time; payment method; and details with respect to the payment method such as the debit or credit card used, financial account associated with the card, name of the financial institution, account type, and account number; or any combination thereof. As used herein, a “financial institution” may include a central bank, a retail bank, a commercial bank, an internet bank, a credit union, a savings and loan association, an investment bank, an investment company, a brokerage firm, an insurance company, a mortgage company, a tax authority (e.g., Mexico’s Tax Administration Service (SAT), Argentina’s Federal Administration of Public Revenue (AFIP), etc.), a digital currency exchange, a cryptocurrency exchange, a digital currency provider, blockchain, a utility company, or other service provider. As used herein, a “financial account” may include a cash account, a bank account (e.g., a checking account, a savings account, etc.), an investment account, or any combination thereof. As used herein, “bank account” may include any type of account at a financial institution or brokerage firm worldwide. A cash account may include a “safe,” “cookie jar,” “wallet,” or any other receptacle where cash or cash equivalents or cryptocurrencies are stored. As used herein, Paybook™ is an example of a “transaction management platform.” Transaction management platforms generally enable financial management, for example, by linking a user’s financial accounts to access transaction information. In the examples, transaction management platforms may provide real-time or near-real-time transaction information. The Paybook™ transaction management platform has additional features beyond those of conventional transaction management platforms, including enabling the use of thematic repositories to organize transactions by topic, as described at least in part in U.S. Patent No. 10,121,208 and U.S. Patent Application Serial No. 15 / 433,966 (U.S. Patent Publication No. 2017-0161844), each of which is incorporated herein by reference.Examples of mainstream transaction management platforms include Venmo™, Mint™, QuickBooks™, and Quicken™. Additionally, Paybook has publishing and sharing capabilities not found in mainstream transaction management platforms. For example, Glass™ is a financial social network partnered with Paybook™ that allows users to publish financial transactions and enables others to access and interact with the data. Exemplary systems described herein may include one or more processors, memory, and one or more transaction management modules and one or more financial social modules. The transaction management module(s) may be maintained in memory and run on one or more of these processors to configure the system to perform actions. These actions may include linking a user account on the transaction management platform to an entity's financial account at a financial institution, receiving raw transaction data from a financial institution, publishing the transaction data, and / or publishing additional information about the transaction data. The transaction management module(s) enable the transaction management platform. Based at least in part on the transaction data associated with the transaction, the transaction management module(s) can determine that the transaction is associated with at least one thematic repository from a plurality of thematic repositories. An individual thematic repository from the plurality of thematic repositories can be configured, for example, to aggregate information from a plurality of financial transactions that are individually determined to be associated with a theme within that individual repository. A user can create a thematic repository to manage transactions for one or more financial accounts that share one or more attributes under a common theme as defined by the user. In response to a request related to the transaction, at least an indication can be provided that the transaction is associated with that at least one thematic repository from the plurality of thematic repositories. Additionally or alternatively, based on transaction data, the transaction management module(s) may determine that a transaction can be categorized into one or more types of categories. An entity associated with a financial account can include one or more individuals, businesses, non-profit organizations, political campaigns, government entities, etc. As used herein, an “entity” refers to a person or organization with whom a financial account is associated and to whom the financial transactions of that account are ultimately attributed. As used herein, a “user” refers to a person who has an account with the transaction management platform and who may have access to, or other permissions for, one or more of an entity’s financial accounts. Additionally or alternatively, the system can make raw transaction data processable at different levels by different stakeholder circles of an entity by associating the transaction data with information that defines the granularity and amount of transaction data that each stakeholder circle is entitled to see. For example, the system can automate the collection of transaction data and thereby reduce the manual efforts required to disseminate transaction data. On the other hand, the techniques described herein can provide entities with a means of demonstrating their financial integrity by leaving their transactions open, thereby differentiating themselves in the market. Conversely, the techniques described herein can impede illicit financial activity by allowing others to review transaction data and by providing indications of any changes to that data. Through the increased transparency provided by the techniques described herein, transaction data can be made publicly available for viewing and use in a way that ensures no manipulation of the raw transaction data by the public (or ensures that any manipulation is traceable and detectable). This fosters greater confidence in how entities spend funds (e.g., how donations are handled, how a nonprofit allocates funds, etc.). In one example, the entity is a nonprofit organization that collects, manages, and distributes donations. In this example, the nonprofit would like to publish financial transaction data to enhance trust with stakeholders and the public and provide assurance that the transaction data has not been altered.The techniques described here enable this type of publication. The techniques described in this document allow transactions to be viewed by stakeholders in real time. Additionally, the techniques described in this document increase the usefulness of transaction data for consumers of transaction data by providing categorizations and summaries of transaction data. Furthermore, the techniques described herein enable the publication of transaction data on a financial social network (which may be part of, or separate from, the transaction management platform) that provides the necessary tools for social collaboration regarding financial transactions and facilitates collective intelligence. Collective intelligence can be both deeper and broader than what a financial auditor or controller can achieve and can identify transactions that may require more detailed scrutiny by the entity. The reference to a “modality” herein does not limit the described elements to a single modality; all described elements may be combined in any modality in any number of ways. Furthermore, for the purposes of interpreting this specification, the use of “or” herein means “and / or” unless otherwise stated. The use of “a” herein means “one or more” unless otherwise stated. The use of “comprising,” “comprising,” “comprising,” “including,” and “including” are interchangeable and not intended as limiting. Also, unless otherwise stated, the use of terms such as “first,” “second,” “third,” “superior,” “inferior,” and the like do not denote any spatial, sequential, or hierarchical order or importance, but are used to distinguish one element from another.It should be noted that the use of the terms “and / or” and “at least one of”, for example, in the cases of “A and / or B” and “at least one of A and B”, is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B). As an additional example, in the cases of “A, B, and / or C” and “at least one of A, B, and C”, such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of the second and third listed options (B and C) only, or the selection of all three options (A and B and C).This can be extended, as is readily apparent to a person with knowledge of this and related subjects, to all the listed elements. It should also be appreciated by those experienced in the subject that any block diagram, step, or subprocess in this document represents conceptual views of illustrative systems that incorporate the principles of this subject matter. Similarly, it will be appreciated that any flowchart, flow diagram, state transition diagram, pseudocode, and the like represent various processes that can be substantially represented in computer-readable media and executed by a computer or processor, whether or not such computer or processor is explicitly shown. The order in which the methods are described is not intended to be interpreted as a limitation, and any number of the method blocks described may be deleted, moved, added, subdivided, combined, and / or modified in any order to implement the methods, or alternative combinations or subcombinations.Also, while the steps, subprocesses, or blocks are sometimes shown as being performed serially, some of them may actually be performed in parallel, or at different times, as anyone experienced in the subject will recognize. Furthermore, any specific number indicated herein is merely illustrative; alternative implementations may employ different values ​​or intervals. Additionally, the methods can be implemented on any suitable hardware, software, firmware, or combination thereof. Throughout this disclosure, reference is made to the presentation of a UL. It should be noted that in some examples, an application or module may generate instructions to present a UL and may execute those instructions to present the UL. Alternatively, in some examples, a first application or module may generate the instructions and send them to a second application or module. In such examples, the second application or module may execute the received instructions to present the UL. In some examples, the first application or module and the second application or module may run on the same computing devices or on different computing devices. Exemplary operating environment Ί Figure 1 illustrates an exemplary operating environment 100 in which the techniques described herein can be implemented, as described herein. The operating environment 100 may include one or more user devices 102(1)-102(N) and one or more tracker devices 104(1)104(N). One or more of these user devices 102(1)-102(N) and one or more of these tracker devices 104(1)-104(N) may be coupled to one or more server devices 106(1)-106(N) (also referred to herein as a “server(s)”), through one or more networks 108(1)108(N). In the examples, the operating environment 100 may include one or more third-party service devices 110(1)-110(N) (also referred to herein as “third-party device(s”)) and one or more financial institution servers 112(1)-112(N). The operating environment 100 may also include one or more storage devices 114(1)-114(N).System 120 includes server(s) 106(1)-106(N) and storage device(s) 114(1)-114(N). For simplicity of reference, the components throughout this disclosure may be referred to in the singular form and in relation to a single, generalized reference number. For example, one or more such user devices 102(1)-102(N) (i.e., the plural form) may be referred to as a user device 102 (i.e., the singular form). However, it should be understood that the use of the singular form may include the plural form in certain implementations. One or more of the user device 102, the tracker device 104, or the server 106 can include any type of computing device that is generally configured to perform an operation. For example, one or more of the user device 102, the tracker device 104, or the server 106 can be implemented as a laptop computer, a desktop computer, a server, a smartphone, an e-reader, a mobile phone, a personal digital assistant (PDA), a portable navigation device, a portable gaming device, a tablet computer, a watch, a portable media player, a television, a digital box, an in-car computing system, an appliance, a camera, a robot, a hologram system, or a home-based computing system (e.g., an intercom system, a home multimedia system, etc.).), a projector, an automated teller machine (ATM), a pair of glasses with computing capabilities, etc. In certain implementations, a user can use user device 102 to perform actions including, but not limited to, managing, sharing, and / or publishing transaction activity. User device 102 is discussed later, at least in relation to Figure 2. In certain implementations, a follower can use follower device 104 to perform actions including, but not limited to, reviewing, viewing, reacting to, sharing, following, or otherwise consuming published data. Follower device 104 is discussed later, at least in relation to Figure 3. Operating environment 100 includes system 120. System 120 includes server(s) 106(1)-106(N) and storage device(s) 114(1)-114(N). The storage device 114 can store, for example, transaction data. The user device 102, the tracker device 104, the server 106, or any combination of the IVIA / t / ZUZZ / UÓ 1400 themselves can be coupled to storage device 114 via network 108. Additionally, or alternatively, storage device 114 can reside locally with respect to user device 102, server 106, or both. In certain implementations, storage device 114 can include one or a combination of computer-readable media. Computer-readable media includes computer storage media and computer-readable signals. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, solid-state memory, phase-change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, and compact disc read-only memory (CD-ROM).Digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by means of a computing device. Additionally, in some examples, computer-readable media may be associated with transient computer-readable signals (in compressed or uncompressed form). Examples of computer-readable signals, whether modulated using a carrier or not, include, but are not limited to, signals that a computer system hosting or running a computer program may be configured to access, including signals downloaded via the Internet or other networks. Figure 1 includes a component selection block diagram of one or more example server devices 106(1)-106(N). The server 106 may include one or more processors 130, memory 132, one or more operating systems 134, one or more transaction management modules 116, one or more financial social modules 118, other modules and data 136, one or more displays 140, one or more input / output (I / O) components 142, one or more network interfaces 144, or any combination thereof. A processor 130 may itself include one or more processors or processing cores. For example, one or more such processors 130 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitry, and / or any device that manipulates signals based on operational instructions. In some examples, one or more such processors 130 may be one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. One or more of such processors 130 may be configured to obtain and ML / t / ZUZZ / UÓ execute computer-readable instructions executable by the processor stored in memory 132. Depending on the server configuration, memory 132 can be an example of computer storage media and may include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of technology for storing information such as computer-readable instructions executable by the processor, data structures, program modules, or other data as discussed previously. For example, memory 132 may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and / or other computer-readable media technologies.Furthermore, in some examples, server 106 may access external storage, such as RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and that can be accessed by one or more processors directly or through another computing device or network. Accordingly, server 106 may include computer storage media capable of storing instructions, modules, or components that can be executed by one or more processors. Additionally, when mentioned, non-transient computer-readable media and computer storage media exclude media such as power, carrier signals, electromagnetic waves, and signals themselves. Additionally, computer-readable media, including memory 132, may be associated with transient computer-readable signals (in compressed or uncompressed form). Examples of computer-readable signals, whether modulated using a carrier or not, include, but are not limited to, signals that a computer system hosting or running a computer program may be configured to access, including signals downloaded via the Internet or other networks. Memory 132 can be used to store and maintain any number of functional components that are executable by one or more of said processors 130. In some implementations, these functional components include instructions or programs that are executable by one or more of said processors and that, when executed, implement operational logic to carry out the actions and services attributed above to the server 106. The term “module” is intended to describe exemplary divisions of the software for discussion purposes and is not intended to describe any type of requirement, method, manner, or necessary organization. Accordingly, while several “modules” are discussed, their functionality, similar functionality, or both, could be accommodated differently (e.g., combined into fewer modules, separated into more modules, etc.). Modules may include computer instructions / code that can be stored in memory 132 and that can be executed by one or more of such processors 130. In addition, memory 132 may include one or more additional functional components, such as the operating system 134, to control and manage different server functions 106 and to enable basic user interactions. Furthermore, memory 132 may store data, data structures, and similar items used by the functional components. Depending on the type of server 106, memory 132 may also optionally include other functional components and data, such as other modules and data 136, which may include one or more programs, drivers, etc., and the data used or generated by the functional components. Furthermore, the server 106 may include many other logical, programmatic, and physical components, of which those described are merely examples relevant to the discussion in this document. Server 106 may be configured with, or otherwise include, one or more transaction management modules 116(1)-116(N) and one or more social financial modules 118(1)-118(N). In the examples, transaction management module 116 and social financial module 118 provide the functionality to carry out the techniques described in this disclosure. The transaction management module(s) 116 may include one or more of a user interface module 146, a subject repository module 148, a transaction entry module 150, a transaction configuration module 152, a syncing application programming interface (API) 158, a publishing module 156, or any combination thereof. For the purposes of clarity in this disclosure, the transaction management module 116 may consist of executable computer code that can be executed by one or more processors 130 to enable a user of user device 102 to perform the actions described herein. The user interface module 146 can be maintained in memory 132 and executed on processor(s) 130 to perform actions. These actions may include receiving a user request related to an account with the transaction management platform and, in response to the request, presenting an aggregation of information from multiple transactions identified as associated with the account. Alternatively, the actions may include generating a user interface that allows a user to perform actions such as viewing, sorting, filtering, or any combination thereof, at least a portion of the aggregation of information at varying levels of granularity. Alternatively, the actions may also include linking a financial account to the user's account with the transaction management platform.Additionally or alternatively, UI module 146 may cause a user interface to be provided to a follower. Additionally or alternatively, UI module 146 may cause a user interface to be provided to a user to prompt for the entry of user credentials for, for example, a transaction management platform account and / or a financial account. In the examples, UI module 146 may provide a user interface that can be used as a vehicle to operate the functionality provided by transaction management module 116, including one or more functions that allow a user to enter data, receive data, view data, configure data, and share data. MA / t / ZUZZ / UÓ 1400 data, publish data, or any combination thereof. In certain cases, the user interface module 146 may be configured to provide a user interface that corresponds to a particular server 106, user device 102, or third-party services device 110 being used. For example, information may be presented to the user or viewer differently when displayed on a mobile phone than when displayed on a personal computer. In some examples, the user interface can be provided to a user or follower through a web browser (e.g., software as a service (SaaS)), through a downloadable client application, or both. The user interface module 146 can be configured to provide a summary view related to the features provided by the transaction management module(s) 116 or the financial social module(s) 118. Thematic repository module 148 can assign at least a portion of transaction data associated with a transaction to a first repository. Transaction management module(s) 116 can determine, based on the transaction data, that the transaction is associated with a first theme and a second theme. The first repository can be configured to provide an aggregation of information associated with multiple financial transactions that are individually determined to be associated with the first theme. Thematic repository module 148 can assign at least a portion of the transaction data associated with the transaction to a second repository. The second repository can be configured to provide an aggregation of information associated with multiple financial transactions that are individually determined to be associated with the second theme. Transaction Entry Module 150 can be configured to allow the reception of transaction data. A user can be allowed to enter information to configure various accounts, thematic deposits, connections / collaborators, and the like, in order to more efficiently track, manage, or publish financial transactions. Transaction Entry Module 150 can be configured to allow the creation of multiple financial accounts with the transaction management platform to enable the tracking of financial transaction information. Transaction Entry Module 150 can also be configured to allow a user to enter information about one or more entities for which the user would like to manage transaction activity using the transaction management platform (for example, via Transaction Management Module 116).For example, the user may be allowed to enter data regarding employees who might collaborate with the user regarding certain transaction activity using the transaction management platform. The transaction entry module 150 can also be configured to allow the entry of transaction data. The transaction entry module 150 can cause the received transaction data to be stored (for example, on storage device 114 or in memory 132). IVIA / t / ZUZZ / UÓ 1400 After receiving the transaction data, the transaction entry module 150 can provide the transaction data to the user through a user interface. The transaction configuration module 152 can provide the necessary tools for configuring transaction data. For example, the transaction configuration module 152 can receive a request from a user to configure transaction data. The request might include providing any appropriate indication that the user wants to configure transaction data, such as selecting a menu item designated to initiate transaction data configuration. However, in some cases, the transaction configuration module 152 might proactively present a user with the option to configure transaction data, or it might configure transaction data according to default parameters without a user request. The transaction configuration module 152 can provide, through the user interface, a means to configure transaction data (for example, by editing text or graphics presented to the user). In addition, the user and / or tracker can configure transaction data by selecting menu items through a user interface or by any other method suitable for transmitting configuration instructions to the transaction configuration module 152. When the user device 102 or tracker device 104 provides a touchscreen or similar technology, the transaction data can be configured using touchscreen gestures to indicate how the user wishes to configure the transaction data.The configuration of transaction data must not alter the underlying raw transaction data; if, when configuring transaction data, the raw transaction data is altered, the change will be logged and / or indicated as described herein. In the examples, setting up transaction data includes adding annotations, categorizations, and / or electronic documents that are determined to be associated with the transaction data. In the examples, the transaction data configuration can generate configuration data, and the transaction configuration module 152 can associate the generated configuration data with the transaction data. The transaction configuration module 152 can cause the transaction data and / or the associated configuration data to be stored (for example, on storage device 114 or in memory 132). Synchronization API 158 may be included in and / or associated with transaction management module 116. Synchronization API 158 may receive and transmit data between transaction management module 116 and the financial institution server 112, and between transaction management module 116 and the third-party services device 110. Synchronization API may be configured to implement rules and / or instructions to perform actions that include one or more of linking financial accounts to transaction management module 116, retrieving transaction data, updating transaction data, or normalizing transaction data. The publishing module 156 can share a selected account, profile, thematic repository, or individual transaction(s) between a user and a follower and / or between followers. The module MA / 1400 of publication 156 can also publish the selected account, profile, thematic deposit, or individual transaction(s) in a public forum and / or on a financial social network. The publication 156 module can publish the selected account, profile, thematic deposit, or individual transaction(s) in a forum within or outside the transaction management platform. The financial social module 118 may consist of executable computer code that can be run by one or more processors. The financial social module 118 may allow a user to interact regarding transaction activity in a social forum. For example, the financial social module 118 may provide the necessary elements for integrating one or more financial social networks with the transaction management platform. A financial social network may be provided by the financial social module 118 so that a user of the transaction management platform can interact with other users of the transaction management platform. In addition, external social networks may be integrated into the transaction management platform through third-party applications, thereby allowing a user of the transaction management platform to connect with users of external social networks. The financial social module 118 can receive, from a user device 102, a selection of at least one follower with whom to share a selected amount, profile, thematic deposit, or individual transaction(s). The financial social module 118 can establish a sharing permission policy. In some cases, the user can select the parameters for the sharing permission policy. In other cases, a default or system-defined sharing permission policy can be set. The sharing permission policy can define the proposed sharing relationship between a user and one or more followers, and / or between one or more followers. That is, the sharing permission policy can define rules regarding what can and cannot be shared between the user and one or more followers, or between followers. The financial social module 118 can determine if a follower has an account with the transaction management platform. Based on the determination that the follower has a transaction management account, the financial social module 118 can notify the follower of a proposed sharing relationship. The financial social module 118 can also determine if the follower accepts the proposed sharing relationship. If the follower accepts the proposed sharing relationship, then the financial social module 118 can send a notification to user device 102 that the follower accepted the sharing relationship. If it is determined that the follower does not have an account with the transaction management platform, the financial social module 118 can send the follower an invitation to create a transaction management account. The financial social module 118 can do this automatically or at the user's request. The financial social module 118 can determine whether the follower creates a transaction management account. In at least one example, server 106 may include one or more displays 140. Depending on the type of computing device(s) used as server 106, display 140 may employ any suitable display technology. For example, display 140 may be a liquid crystal display, a MA / t / ZUZZ / UÓ 1400 plasma display, cathode ray tube (CRT) monitor, light-emitting diode display, organic light-emitting diode (OLED) display, electronic paper display, or any other suitable display type capable of presenting digital content. In some examples, display 140 may have a touch sensor associated with it to provide a touchscreen configured to receive touch inputs to enable interaction with a graphical interface presented on display 140. Accordingly, the implementations herein are not limited to any particular display technology. Alternatively, in some examples, server 106 may not include display 140, and information may be presented by other means, such as audibly. The I / O component 142 can be configured to allow a user to interface with the server 106 through one or more I / O devices. The I / O component 142 can provide input devices including one or more of a display 140, speakers (not shown), a microphone (not shown), a keyboard (not shown), a mouse (not shown), a camera (not shown), an optical reader (not shown), a touchpad (not shown), a haptic output device (not shown), or any combination thereof. Network interface(s) 144 may include one or more hardware interfaces and components to enable communication with other devices, either through network(s) or directly. For example, network interface(s) 144 may enable communication through one or more networks, which may include, but are not limited to, any type of network known in the field, such as a local area network or a wide area network, such as the Internet, and may include a wireless network, such as a cellular network, a local wireless network, such as Wi-Fi, and / or short-range wireless communications, such as Bluetooth®, BLE, NFC, RFID, a wired network, or any other such network, or any combination thereof, etc. A network may include both wired and wireless communication technologies, including Bluetooth®, BLE, Wi-Fi, and cellular communication technologies, as well as cable or fiber optic technologies, etc.The components used for such communications may depend at least in part on the type of network, the selected environment, or both. Server 106 may also include other devices, including a GPS device (not shown) capable of providing location information. In addition, Server 106 may include one or more sensors (not shown), such as an accelerometer, gyroscope, compass, proximity sensor, camera, microphone, and / or a switch, as previously discussed. Furthermore, Server 106 may include other components not shown, such as removable storage, a power supply (such as a battery and power control unit), a printer, and so on. In the examples, at least one of the user device 102 or server 106 can access transaction data from one or more financial institution servers 112(1)-112(N). The financial institution server(s) 112 can include servers associated with one or more banks, brokerage firms, credit card companies, finance companies, and the like. User device 102, server 106, or both can provide transaction data received from the MA / t / ZUZZ / UÓ 1400 Financial Institution Server(s) 112 such that a user can manage transactions that correspond to transaction data received from Financial Institution Server 112. Financial Institution Server(s) 112 may include various components similar to those of User Device 102, Server Device 104, Server 106, or any combination thereof. Therefore, it should be understood that any disclosure provided herein with respect to User Device 102, Server 106, or both, may also apply to Financial Institution Server(s) 112. In some examples, the operating environment 100 may include third-party service device(s) 110(1)-110(N). The third-party service device 110 operates directly between server 106 and the financial institution server 112 to request and receive transaction data from a financial institution. The third-party service device 110 may include a third-party API. In some implementations, the operating environment 100 may include one or more quality control (QC) devices 160(1)-160(N). The user device 102, the server 106, or both, may be coupled to the QC device 160 via the network 108. Alternatively, the QC device 160 may reside locally with respect to the user device 102, the server 106, or both. The QC device 160 may be configured to verify the accuracy and proper format of transaction data received from any of the financial institution servers 112, the user device 102, or the server 106 in response to receiving the transaction data and / or as a result of user input, or to perform other quality control measures with respect to such transaction data.In some examples, the QC 160 device may include or access one or more databases that store templates or other data to verify the proper format of different types of transaction data. For example, the format of transaction data received from user device 102, server 106, or both, can be compared to information stored in one or more of these databases. In some examples, the QC 160 device is able to access templates, format data, or both, from financial institution server(s) 112. The QC 160 device can perform quality control measurements automatically. Additionally, or alternatively, at least some of the quality control measurements performed by the QC 160 device may not be automatic (i.e., operator involvement may be required). The QC 160 device may include various components similar to those of the user device 102, the server 106, or both. Therefore, it should be understood that any disclosure provided herein regarding the user device 102, the server 106, or both, may also apply to the QC 160 device. Those experienced in the subject matter will appreciate that the hardware components and various functional modules depicted in Figure 1 and elsewhere may vary. The illustrative components are not intended to be exhaustive, but rather representative to highlight components used to implement the subject matter disclosed in this application. For example, other devices / components may be used in addition to or instead of the hardware depicted. Furthermore, the various storage and memory components illustrated may MA / t / ZUZZ / UÓ 1400 can alternatively be located in any storage or memory across the 108 network. The example shown is not intended to imply architectural or other limitations with respect to the subject matter of this disclosure. Exemplary user device(s) Figure 2 illustrates a block diagram of selected components of one or more user devices 200 (for example, user device 102 in Figure 1), as described herein. The user device 200 may include one or more processors 202, memory 204, one or more operating systems 206, one or more user transaction review interfaces 208, one or more user interface modules 210, one or more transaction entry modules 212, other modules and data 214, one or more displays 216, one or more input / output (I / O) components 218, one or more network interfaces 220, or any combination thereof. Each processor 202 may itself include one or more processors or processing cores. For example, one or more such processors 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitry, and / or any device that manipulates signals based on operational instructions. In some examples, one or more such processors 202 may be one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. One or more such processors 202 may be configured to fetch and execute processor-executable, computer-readable instructions stored in memory 204. Depending on the configuration of user device 200, memory 204 can be an example of computer storage media and may include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of technology for storing information such as computer-readable instructions executable by the processor, data structures, program modules, or other data as discussed previously. For example, memory 204 may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and / or other computer-readable media technologies.Furthermore, in some examples, the user device 200 may access external storage, such as RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and that can be accessed by one or more processors directly or through another computing device or network. Accordingly, memory 204 may include computer storage media capable of storing instructions, modules, or components that can be executed by one or more processors 202. In addition, when mentioned, non-transient computer-readable media and computer storage media exclude media such as power, carrier signals, electromagnetic waves, and signals themselves. The modules may include computer instructions / code that can be stored in memory 204 and that can be executed by one or more of such processors 202. Memory 204 may be associated with transient computer-readable signals (in compressed or uncompressed form). Examples of computer-readable signals, whether modulated using a carrier or not, include, but are not limited to, signals that a computer system hosting or running a computer program may be configured to access, including signals downloaded via the Internet or other networks. Memory 204 may be used to store and maintain any number of functional components that are executable by one or more of said processors 202. In some implementations, these functional components include instructions or programs that are executable by one or more of said processors and that, when executed, implement operational logic to carry out the actions and services attributed above to the user device 200. In addition, memory 204 may include one or more additional functional components, such as the operating system 206, to control and manage different functions of the user device 200 and to enable basic user interactions. Furthermore, memory 204 may also store data, data structures, and the like, which are used by the functional components. Memory 204 may also include one or more user transaction review interfaces 208. In some examples, the user transaction review interface(s) 208 present transaction information or transaction data for user review. In the examples, the user transaction review interface(s) 208 may present manually uploaded transaction data for user review before the transaction data is transmitted or published to the server. Memory 204 may contain one or more user interface modules 210. A user interface module 210 may be maintained in memory 204 and executed on processor(s) 202 to perform actions. User interface module 210 may cause a user interface to be provided to a user on the screen(s) of user device 200. In the examples, user interface module 210 may cause a user interface to be provided that allows a user to perform actions associated with transaction management module 116 (for example, by means of a mobile application associated with transaction management module 116). User interface module 210 on user device 200 may perform actions similar to user interface module 146 of transaction management module 116. In certain cases, the user interface module 210 can be configured to provide a user interface tailored to the specific user device 200 being used. For example, information may be presented differently to the user on a mobile phone than on a personal computer. In some examples, a user interface can be provided to a user through a web browser (e.g., software as a service (SaaS)), or through a client application. MA / t / ZUZZ / UÓ 1400 download it, or both. The user interface module 210 can provide a summary view related to transaction management features. Additionally, memory 204 can include a transaction input module 212. The transaction input module 212 can be configured to receive transaction data in a variety of ways. It can be configured to accept transaction data that will be tracked by the transaction management module 116 and / or published by the financial social module 118. The transaction input module 212 can store received transaction data. In the examples, the transaction input module 212 can cause the transaction data to be stored in memory 204. When the transaction input module 212 receives the transaction data, the transaction input module 150 can provide the transaction data to the user through a user interface. Depending on the type of user device 200, memory 204 may also optionally include other functional components and data, such as other modules and data 214. In the examples, memory 204 may include applications provided by the transaction management platform or the financial social platform. Furthermore, the user device 200 may include many other logical, programmatic, and physical components, of which those described are merely examples relevant to the discussion in this document. The I / O components 218 can be configured to allow a user to interface with the user device 200 by means of one or more I / O devices. The I / O components 218 can provide an interface for such devices as a display 216, speakers (not shown), a microphone (not shown), a keyboard (not shown), a mouse (not shown), a camera (not shown), an optical reader (not shown), a touchpad (not shown), a haptic output device (not shown), or any combination thereof. In at least one example, user device 200 may include one or more displays 216. Depending on the type of computing device(s) used as user device 200, display 216 may employ any suitable display technology. For example, display 216 may be a liquid crystal display, a plasma display, a cathode ray tube (CRT) monitor, a light-emitting diode display, an organic light-emitting diode (OLED) display, an electronic paper display, or any other suitable display type capable of presenting digital content. In some examples, display 216 may have a touch sensor associated with it to provide a touchscreen configured to receive touch input, enabling interaction with a graphical interface presented on the display 216.Consequently, the implementations in this document are not limited to any particular display technology. Alternatively, in some examples, the user device 200 may not include the display 216, and the information may be presented by other means, such as audibly. One or more of these 220 network interfaces may include one or more hardware interfaces and components to enable communication with other different devices, such as through network(s) or MA / t / ZUZZ / UÓ 1400 directly. For example, network interface(s) 220 may allow communication across one or more networks, which may include, but are not limited to, any type of network known in the field, such as a local area network or a wide area network, such as the Internet, and may include a wireless network, such as a cellular network, a local wireless network, such as Wi-Fi, and / or short-range wireless communications, such as Bluetooth®, BLE, NFC, RFID, a wired network, or any other such network, or any combination thereof, etc. A network may include both wired and wireless communication technologies, including Bluetooth®, BLE, Wi-Fi, and cellular communication technologies, as well as cable or fiber optic technologies, etc. The components used for such communications may depend at least in part on the type of network, the selected environment, or both.The protocols for communicating through such networks are well known and will not be discussed in detail in this document. Other components included in User Device 200 may include a GPS device (not shown) capable of providing location information. Additionally, User Device 200 may include one or more sensors (not shown), such as an accelerometer, gyroscope, compass, proximity sensor, camera, microphone, and / or a switch, as discussed previously. Furthermore, User Device 200 may include other components not shown, such as removable storage, a power source (such as a battery and power control unit), a printer, and so on. Exemplary follower device(s) Figure 3 illustrates a block diagram of selected components of one or more exemplary follower devices 300 (for example, the follower device 104(1)-104(N) of Figure 1), as described herein. The follower device 300 may include one or more processors 302, memory 304, one or more operating systems 306, one or more follower transaction review interfaces 308, one or more user interface modules 310, other modules and data 312, one or more displays 314, one or more input / output (I / O) components 316, and one or more network interfaces 318, or any combination thereof. Each 302 processor may itself include one or more processors or processing cores. For example, one or more such 302 processors may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitry, and / or any device that manipulates signals based on operational instructions. In some examples, one or more such 302 processors may be one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. One or more such 302 processors may be configured to fetch and execute processor-executable, computer-readable instructions stored in 304 memory. Depending on the configuration of the 300 tracker device, 304 memory can be an example of tangible, non-transient computer storage media and may include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of information storage technology, such as computer-readable instructions executable by the processor, data structures, program modules, or other data as discussed previously. For example, 304 memory may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and / or other computer-readable media technologies.Furthermore, in some examples, the tracker device 300 may access external storage, such as RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and that can be accessed by one or more processors directly or through another computing device or network. Accordingly, memory 304 may include computer storage media capable of storing instructions, modules, or components that can be executed by one or more processors 302. Additionally, when mentioned, non-transient computer-readable media and computer storage media exclude media such as power, carrier signals, electromagnetic waves, and signals themselves. The modules may include computer instructions / code that can be stored in memory 304 and that can be executed by one or more of such processors 302. Additionally, in some examples, memory 304 may be associated with transient computer-readable signals (in compressed or uncompressed form). Examples of computer-readable signals, whether modulated using a carrier or not, include, but are not limited to, signals that a computer system hosting or running a computer program may be configured to access, including signals downloaded via the Internet or other networks. Memory 304 can be used to store and maintain any number of functional components that are executable by one or more of said processors 302. In some implementations, these functional components include instructions or programs that are executable by one or more of said processors 302 and that, when executed, implement operational logic to carry out the actions and services previously attributed to the follower device 300. In addition, memory 304 may include one or more additional functional components, such as the operating system 306, to control and manage different functions of the tracker device 300 and to enable basic user interactions. Furthermore, memory 304 may also store data, data structures, and similar items that can be used by the functional components. Additionally, memory 304 may include one or more follower transaction review interfaces 308, which, when executed by processor 302, allow a follower to perform actions related to published transaction data. These actions may include one or more of the following: view, follow, share, comment, express sentiment, save, classify, filter, etc. The computer program code for the follower transaction review interface(s) 308 may be stored locally within the follower device 300, provided via network 108. Memory 304 may contain one or more user interface modules 310. User interface module 310 may be maintained in memory 304 and executed on processor(s) 302 to provide information to the follower. In the examples, the information may pertain to the follower's membership in, or access to, the financial social network. User interface module 310 may cause a user interface to be provided to a follower on screen(s) 314 of the follower device 300. In the examples, user interface module 210 may cause a user interface to be provided that allows a follower to perform actions associated with financial social module 118 (for example, by means of a mobile application associated with financial social module 118). User interface module 310 of the follower device 300 may perform actions similar to user interface module 146 of financial social module 118. In certain cases, the 310 user interface module can be configured to provide a user interface tailored to the specific 300 tracker device being used by the tracker. For example, information may be presented differently to the tracker on a mobile phone than on a personal computer. In some instances, the user interface may be provided to a tracker via a web browser (e.g., Software as a Service (SaaS)), via a downloadable client application, or both. Depending on the type of tracker device 300, memory 304 may also optionally include one or more other functional components and data, such as other modules and data 312, which may include programs, drivers, etc., and data used or generated by the functional components. In the examples, memory 304 may include applications provided by the transaction management platform or the financial social platform. Furthermore, the tracker device 300 may include many other logical, programmatic, and physical components, of which those described are merely examples relevant to the discussion in this document. In at least one example, the tracker device 300 may include one or more displays 314. Depending on the type of computing device(s) used as the tracker device 300, the display 314 may employ any suitable display technology. For example, the display 314 may be a liquid crystal display, a plasma display, a cathode ray tube (CRT) monitor, a light-emitting diode display, an organic light-emitting diode (OLED) display, an electronic paper display, or any other suitable display type capable of presenting digital content. In some examples, the display 314 may have a touch sensor associated with it to provide a touchscreen configured to receive touch input, enabling interaction with a graphical interface presented on the display 314.Consequently, the implementations in this document are not limited to any particular display technology. Alternatively, in some examples, the 300 tracker device may not include the 314 display, and the information may be presented by other means, such as audibly. The components of l / O 316 can be configured to allow a follower to interface MA / t / ZUZZ / UÓ 1400 with the tracker device 300 by means of one or more I / O devices. The I / O components 316 can provide an interface for such devices as the display 314, speakers (not shown), a microphone (not shown), a keyboard (not shown), a mouse (not shown), a camera (not shown), an optical reader (not shown), a touchpad (not shown), a haptic output device (not shown), or any combination thereof. Network interface(s) 318 may include one or more hardware interfaces and components to enable communication with other devices, either through network(s) or directly. For example, network interface(s) 318 may enable communication through one or more networks, which may include, but are not limited to, any type of network known in the field, such as a local area network or a wide area network, such as the Internet, and may include a wireless network, such as a cellular network, a local wireless network, such as Wi-Fi, and / or short-range wireless communications, such as Bluetooth®, BLE, NFC, RFID, a wired network, or any other such network, or any combination thereof, etc. A network may include both wired and wireless communication technologies, including Bluetooth®, BLE, Wi-Fi, and cellular communication technologies, as well as cable or fiber optic technologies.The components used for such communications may depend, at least in part, on the type of network, the selected environment, or both. The protocols for communicating across such networks are well known and will not be discussed in detail herein. Other components included in the 300 tracker device may include a GPS device (not shown) capable of providing location information. Additionally, the 300 tracker device may include one or more sensors (not shown), such as an accelerometer, gyroscope, compass, proximity sensor, camera, microphone, and / or a switch, as discussed previously. Furthermore, the 300 tracker device may include other components not shown, such as removable storage, a power source (like a battery and power control unit), a printer, and so on. Linking an entity's financial account to a user's account with the transaction management platform The techniques described in this document allow a user to receive transaction data in real time or near real time, for one or more financial accounts. Each user of the transaction management platform must create a global account. Each user can have multiple associated profiles, such as a personal profile and a business profile for an entity with which the user is associated. Furthermore, a user can obtain access rights to other profiles. A user can create multiple paybooks within each of their associated profiles. A user can share as many or as few of these paybooks as they wish and can select an audience with whom to share them. A user can also link financial accounts to the transaction management platform to allow the transaction management platform to receive transaction data from a financial institution. Figures 4A, 4B, 4C, 4D, and 4E are a flowchart illustrating an exemplary 400 process for linking a financial account to a transaction management platform, as described herein. Block 402 illustrates providing, for display on a user device, a first user interface that includes a request for user credentials for a transaction management platform. In the examples, the user interface module 146 of the transaction management module 116 can provide the first user interface. Block 404 illustrates receiving and storing user credentials. User credentials are associated with the user's account on the transaction management platform and, if validated, can provide user access to transaction data for one or more financial accounts. The transaction management module can receive and store user credentials, at least partially, in response to receiving them through the first user interface. The transaction management module can cause user credentials to be stored on storage device 114 or in memory 132. Block 406 illustrates providing, for display on a user device, a second user interface that includes a request for a jurisdiction for a financial account to be linked. In some examples, the jurisdiction might be the location of the financial institution to which the account is associated, or, if the financial institution is multinational, the jurisdiction might be the jurisdiction in which the account was opened or is managed. In the examples, a jurisdiction could be a country or another geographic or political region. In the examples, the first user interface might be provided by user interface module 146 of transaction management module 116.In several examples, the second user interface that provides the jurisdiction request may be the same as the first user interface described in Block 402 (for example, additional information may be presented after validating user credentials) or it may be a different user interface. In the examples, the financial account jurisdiction may be obtained through the transaction management module by means other than user input in a user interface (for example, from financial account information associated with the user profile or otherwise stored by System 120). Block 408 illustrates receiving and storing jurisdiction. The transaction management module can receive and store jurisdiction, at least partially, in response to receiving jurisdiction. The transaction management module can cause user credentials to be stored on storage device 114 or in memory 132. Block 410 illustrates how to determine, based at least in part on the jurisdiction, the financial management module or a third-party device to communicate with a financial institution when linking the financial account to the financial management platform. In the examples, the transaction management module executes rules to determine, based at least in part on the jurisdiction, whether a third party or the financial management module will be used to communicate with the financial institution for the purpose of linking the account. In some examples, the transaction management module determines whether the third party or the financial management module will be used based on additional or alternative attributes of the financial account beyond the jurisdiction. In one example, the jurisdiction of a financial account is determined to be the United States.Based on the application of the rules, the transaction management module determines which third-party service will be used to interface with the financial institution. In cases where more than one third-party service is potentially capable and available to perform the connection, the third-party service can be selected based on priority or manually by the user. When selected based on priority, the transaction management module can implement a fault-tolerance system that prioritizes the third-party service based on factors such as latency, stability, cost, data richness, etc. If an issue arises with the priority of the third-party service and / or device, the next priority line can be used.In examples where the financial management module is used to communicate with the financial institution, the transaction management module may act to obtain additional account information from the user. Block 412 illustrates that, in response to the determination that the financial management module will communicate with the financial institution, a third user interface should be provided for display on a user device. This interface includes a prompt to select the financial institution associated with the financial account. The transaction management module can provide this third user interface to the user device. In one example, the third user interface provides options, either through one or more selectable graphic icons or through a text list, representing multiple financial institutions. The third user interface may include a text field for entering the name of a financial institution, which can be autocompleted if the initial text string is recognized by the transaction management module.Other means of obtaining the identity of the financial institution are also possible (e.g., inserting a URL for the financial institution, etc.). Block 414 illustrates receiving and storing the financial institution. In Block 414, the transaction management module can receive, through the user interface, the user's selection of the financial institution, and the transaction management module can cause the user's selection of the financial institution to be stored in storage device 114 or in memory 132. Block 416 illustrates providing, for display on the user device, a fourth user interface that includes a request for financial account credentials. The fourth user interface may include a request for financial account credentials (e.g., account number, username, password, email address, etc.). Block 418 illustrates receiving the provided financial account credentials. In Block 418, the transaction management module can receive the financial account credentials through the fourth user interface. IVIA / 1400 Block 420 illustrates sending an authentication token to the financial institution for the financial institution and the financial account credentials. Block 422 illustrates receiving and storing an authorization token from the financial institution. After validating the financial account credentials, the financial institution can send the corresponding authorization token to the transaction management module. In the examples, the financial account authorization token can be stored in memory 132, storage device 114, or a synchronization API associated with the transaction management module. Block 448 illustrates transmitting the authorization token and a transaction data request associated with the financial account to the financial institution. In the examples, the transaction management module transmits the request along with the financial account authorization token. In the examples, a synchronization API transmits the request and the financial account authorization token to the financial institution. The request can be received by a synchronization application associated with the financial institution. The synchronization application associated with the financial institution can determine if the financial account authorization token is valid. If the financial account authorization token is valid, the synchronization API associated with the financial institution can determine if there are any additional requirements (for example, answering a security question).If so, the synchronization application can send a message to the transaction management module requesting additional information. The transaction management module can provide other user interfaces that include a request for additional information to fulfill the extra requirement. If authentication fails, the financial institution can send an error message to the transaction management module, and the transaction management module can provide a notification through a user interface. Block 450 illustrates receiving and storing transaction data from the financial institution. The transaction management module can also receive information about the financial account, which may include one or more account names, account types, balances, etc. For a transaction represented in the transaction data, the transaction data may include one or more transaction dates, a transaction description, a transaction amount, and the currency. The transaction management module can then store the transaction data on storage device 114 or in memory 132. Block 452 illustrates transmitting transaction data to a synchronization application programming interface (API) associated with the transaction management module. Block 454 aims to receive transaction data via the financial institution's synchronization API. Block 466 illustrates normalizing transaction data through the synchronization API. Block 468 illustrates transmitting, from the synchronization API, the normalized transaction data and an authentication token to the transaction entry module associated with the transaction management module. The transmission may occur based, at least in part, on the management module. MA / t / ZUZZ / UÓ 1400 transactions query the synchronization API to check if the synchronization API has new transaction data. In the examples, normalized transaction data and an authentication token are passed to the transaction entry module. Block 470 illustrates how the transaction entry module receives and stores normalized transaction data and the authentication token. The transaction entry module receives the authentication token and normalized transaction data by communicating with a third-party service device or by negotiating internally with the synchronization API. The transaction entry module then stores the transaction data and the authentication token, for example, in storage device 114 or memory 132. Based at least in part on the transaction input module that receives the normalized transaction data, the transaction management module can notify the synchronization API that the financial account has been linked and provide the synchronization API with information associated with the financial account (e.g., financial account type, interface type, authentication token, etc.). The synchronization API can determine, based at least in part on rules associated with the transaction management module, how frequently the synchronization API will attempt to synchronize with the financial account and sends an indication of this frequency to the transaction management module. Returning to Figure 4C, Block 432 illustrates providing, in response to the determination in Block 410 that a third-party device will communicate with the financial institution, a third user interface for presentation on a user device, which includes a request to select the financial institution associated with the financial account. A third-party device provides the third user interface to the user device. In the examples, the transaction management module opens a web page, and the web page opens a plugin provided by the third-party device. The plugin communicates directly with the third-party device. The third-party device may provide one or more third-party user interfaces for at least some interactions with the user device (for example, to obtain additional financial account information such as account number, credentials, etc.).In one example, the third user interface provides options, either through one or more selectable graphic icons or through a text list, representing a plurality of financial institutions. The third user interface may include a text field for entering the name of a financial institution, which can be autocompleted if the initial text string is recognized by the third-party device. Other means of obtaining the financial institution's identity are also possible (e.g., inserting a URL for the financial institution, etc.). Block 434 is used to receive and store information from the financial institution. In Block 434, the third-party device receives, through the third user interface, the user's selection of the financial institution with which the financial account is associated. Block 436 illustrates providing, for presentation on the user device, a fourth user interface that includes a request for financial account credentials. The third-party device provides, for presentation on a user device, a fourth user interface that includes a IVIA / t / ZUZZ / UÓ 1400 Request for financial account credentials (e.g., account number, username, password, email address). Block 438 illustrates receiving and storing the provided financial account credentials. The third-party device may receive and store the financial account credentials received in response to the request described in Block 436. Block 440 will send, to the financial institution, an authentication token for the financial institution and the financial account credentials. Block 442 is designed to receive an authorization token from the financial institution and store that token. After validating the financial account credentials, the financial institution can send an authorization token to the third-party device that corresponds to the financial account, and the third-party device can store the authorization token. Block 480 (Figure 4E) illustrates transmitting, via a third-party service to the financial institution, the authorization token and a request for transaction data associated with the financial account. In the examples, the third-party device transmits the request, along with the authorization token. The request can be received by a synchronization application associated with the financial institution. The synchronization application associated with the financial institution can determine if the authorization token is valid. If the authorization token is valid, the synchronization application associated with the financial institution can determine if there are additional requirements (for example, answering a security question). If so, the synchronization application can then transmit a message to the third-party device requesting additional information.The third-party device may provide additional user interfaces, including a request for extra information to fulfill the additional requirement. If the financial institution determines that the authorization token is invalid, the financial institution may transmit an error message to the third-party device, and the third-party device may provide a notification through a user interface. Block 482 illustrates receiving and storing, via a third-party device, transaction data from the financial institution. The third-party device may store the transaction data in local storage on the third-party service. The third-party device may also receive information about the financial account, which may include one or more account names, account types, balances, etc. For a transaction represented in the transaction data, the transaction data may include one or more transaction dates, a transaction description, a transaction amount, and the currency. Block 484 illustrates transmitting, via a third-party device, the transaction data and authorization token to a synchronization application programming interface (API) associated with the transaction management module. Block 486 illustrates receiving, via the financial institution's synchronization API, the transaction data and authorization token. From Block 486, the process continues to Blocks 466, 468, and 470, as described above. ML / t / ZUZZ / UÓ 1400 Update transaction data Once the financial account has been linked to the transaction management platform, the synchronization API can receive transaction data from the financial account and can periodically update the transaction data. Figure 5 is a flowchart that illustrates an exemplary 500 process for updating transaction data for a linked financial account, as described herein. Block 502 illustrates receiving a trigger via a synchronization API to request transaction data from a financial institution. The transaction data can be associated with a financial account at the financial institution. The trigger can include user instructions (for example, through a user interface presented by the transaction management module) to update the financial account. Upon receiving the user instructions, the transaction management module can send instructions to the synchronization API to request the transaction data. Alternatively, the trigger can be an update task in a work queue associated with the synchronization API. Additionally, the trigger can also be the result of a rule that dictates when transaction data should be updated for specific classes, accounts, users, or data.A rule can be based, at least in part, on limits set by financial institutions regarding the maximum frequency or amount of transaction data released from them (e.g., once a day, once every five minutes, 500 transactions per day, etc.). Rules can also be based, or alternatively, on factors such as the location of the financial institution and / or user settings. In some cases, transaction data can be obtained from a financial institution in real time or substantially in real time, meaning at or near the time the transaction occurs. Additionally, or alternatively, rules can be configured to receive transaction data from a financial institution when the institution issues a statement for the financial account. When using a task or rules, a timed process can be used to determine if and / or when the synchronization API should check for updates to transaction data. In the examples, the transaction management module might add a task to a synchronization API job queue when a user renews an account with the transaction management platform. In the examples, after a user account with the transaction management platform expires, no data updates are performed for the account. If the account with the transaction management platform is no longer being updated, the transaction management module might notify the user, for example, via email, text message, a bookmark, or a message in the user interface. Additionally, in the examples, a third-party service device may support a callback function, which feeds transaction data into the synchronization API. Block 504 illustrates, requesting, through the synchronization API and based at least in part ML / t / ZUZZ / UÓ 1400 in the trigger, financial institution transaction data. In the examples, the application process may be similar to that described in relation to Figure 4. Block 506 illustrates receiving transaction data via the synchronization API and the financial institution. In the examples, the reception process may be similar to that described in Figure 4. Block 508 illustrates normalizing transaction data through the synchronization API. In the examples, the normalization process may be similar to that described in relation to Figure 4. Block 510 illustrates transmitting transaction data via the synchronization API and a transaction management module associated with the synchronization API. In the examples, the transmission process may be similar to that described in relation to Figure 4. Block 512 illustrates storing transaction data through the transaction management module. In the examples, the storage process may be similar to that described in relation to Figure 4. Block 514 illustrates performing, through the transaction management module, at least one task related to transaction data. The transaction management module, based at least in part on the receipt of transaction data, can automatically perform at least one of the following tasks: categorize one or more transactions, assign one or more transactions to a specific account, format transaction data, normalize transaction data, publish transaction data, or aggregate transaction data, some of which are described later. In examples where a third-party service is used to communicate with the financial institution, the third-party device may receive a public access key from the financial institution. In these examples, the third-party device may request to open a session and provide the financial institution with the financial account credentials and the public access key. The financial institution may provide the third-party device with a connection token. The third-party device may store the connection token and establish a connection to the financial institution. The transaction management module may receive the connection token from the third-party device and store it. The transaction management module may provide the connection token to the third-party device when transaction data is requested and may receive transaction data through the third-party device. Categorization and summary of transaction data The transaction management module can increase the transparency of transaction data by automatically categorizing and / or summarizing it. In the examples, the tasks the transaction management module can perform on transaction data include categorizing and / or summarizing it. By applying rules to transaction data, the transaction management module can associate individual transactions with one or more categories from one or more category types, and can group transactions by one or more categories. In some examples, the categories can be hierarchical. Additionally or alternatively, the transaction data can be MA / t / ZUZZ / UÓ 1400 can be manually categorized and / or summarized. For example, users can manually tag one or more transactions with categories, before or after automatic categorization, or without automatic categorization. Figure 6 is a flowchart that illustrates an exemplary process for categorizing and summarizing transaction data for a linked financial account, as described herein. Block 602 illustrates receiving transaction data from a financial institution's server via the transaction management module. In one example, the reception process might be similar to that described in Figure 5. Block 604 illustrates how the transaction management module assigns transaction data to one or more categories based, at least in part, on rules that the transaction management module applies to the transaction data. Transaction data can include both data and metadata. The transaction management module can analyze characteristics of the transaction data against a set of rules. A category can be based on a transaction characteristic, such as a geocode, vendor, project, amount, date, historical categorization, expenditure type, employee, and so on. For example, a transaction might be categorized into one or more categories for each of one or more different category types, such as transactions that occurred in 2018, that occurred on shingles, that are associated with a utility provider, and / or that are for an amount greater than $1,000.A non-limiting example of a rule might require that a transaction be categorized as “Office Supplies” if the vendor is identified as “Office Station.” As another non-limiting example, a rule might state that a transaction is categorized as “$100 to $999” if the transaction amount is $500. In some examples, rules can be learned through a machine learning mechanism. For instance, the transaction management module can be configured to automatically categorize transactions based on historical transaction categorization (and trends observed from it). Rules can also be customized based on parameters including, but not limited to, the entity, user, time of day, transaction location, and so on. In at least one example, the transaction management module can train and store data model(s), for example, in the other modules and data 136. In at least one example, the data model(s) can be trained using machine learning mechanisms in which the input data refers to historical transaction categorization. The historical categorizations may have been selected automatically or manually. The input data may include descriptive data indicative of characteristics of the historical transactions and indications of whether categories were overridden by the user. The data model(s) can be trained using supervised learning algorithms (for example, artificial neural networks, Bayesian statistics, support vector machines, decision trees, classifiers, k-nearest neighbor, etc.).), unsupervised learning algorithms (e.g., artificial neural networks, association rule learning, hierarchical clustering, group analysis, etc.), semi-learning algorithms. MA / 1400 supervised, deep learning algorithms, etc. For a particular transaction, a trained data model can produce a similarity score indicating whether the particular transaction is similar to transactions in a given category. If the similarity score meets or exceeds a similarity score threshold (for example, showing that the particular transaction is more similar to the transactions categorized for that particular category), the transaction management module can automatically assign the transaction to that particular category. If the similarity score is below the similarity score threshold, the transaction can be left uncategorized, at least with respect to the type of category being analyzed (for example, transaction location). The machine learning mechanism can learn the similarity metric and the similarity score threshold.Automatic transaction categorization increases the speed at which transaction data can be published and increases the value to followers of the transaction data. Block 606 illustrates storing, through the transaction management module, associations between transaction data and one or more of these categories. The transaction management module can indicate categories using graphic icons displayed adjacent to a transaction record published in a user interface on a user device and / or a tracker device. A user or tracker can also request that one or more categories associated with transactions be displayed by selecting a particular transaction record. The transaction management module can also classify transactions by category (in addition to classifying by date, payee, amount, etc.). This classification can facilitate the coding of the general ledger (GL) for transaction data, which can be manually adjusted if desired.If a rule exists, the transaction management module can apply the rule to the transaction data to automatically categorize a transaction. Block 608 illustrates how to analyze transaction data and associations using the transaction management module. Based at least in part on categorizing transaction data, the transaction management module can analyze transactions to provide additional intelligence and trends regarding the published transaction. In the examples, the transaction management module can generate information related to how many (and which) transactions occurred within a time period (e.g., a month, a year, etc.), how many transactions fall into a given category (e.g., 100 transactions over $1,000, 2 international transactions, etc.), correlations between job position and spending (e.g., managers tend to spend three times more per month than salespeople), and / or the year-over-year increase in marketing expenditures for an entity. Block 610 illustrates providing, through the transaction management module, aggregate and trend intelligence regarding transactions associated with transaction data. Aggregate and trend intelligence can be provided through a user interface presented on a tracker device and / or user device. A user interface may include a data graphics / analysis area. In the examples, the data graphics area may include any type of data chart suitable for reporting transaction data in a way that is useful or desired by the user. IVIA / t / ZUZZ / UÓ 1400 user or tracker. A non-exhaustive list of data chart types may include pie charts, bar charts, line charts, pictograms, tables, or any combination thereof. A user interface presented on the tracker or user device may include a search bar. A tracker or user may search transaction data by means of the search bar. Additionally or alternatively, a tracker or user may search and / or navigate through the transaction data in any appropriate manner, such as by using selected drop-down filters, selected radio button filters, voice commands, and / or a tag cloud. Additionally or alternatively, a user interface presented on the tracker or user device may include a notification area.The notification area can provide information to a tracker or user about transactions. For example, a notification can be displayed upon receiving new transaction data from a financial institution's server or after an indication that previous data has changed. Therefore, the techniques described herein can provide entities, followers, users, stakeholders, auditors, other stakeholders, and / or the public with additional value beyond basic transaction details by means of summarization, aggregation, categorization, and other analyses that might not otherwise be performed or cost-effectively performed. Monitor changes in transaction data Additionally, or alternatively, the transaction management module can assess the integrity of transaction data. In the examples, the transaction management module can monitor transaction data for deletions or alterations that occur after the initial receipt of the transaction data. Figure 7 is a flowchart that illustrates an exemplary process for determining whether transaction data has been changed or deleted after being received from a financial institution, as described herein. Block 702 illustrates receiving transaction data from a financial account via a transaction management module. In the examples, the transaction data can be received directly from the financial account (e.g., not through manual entry or via other platforms, individuals, or institutions, excluding third-party services as described above). The transaction data is accurate to the extent that the financial institution's records are accurate, at least in part due to the automated, direct transmission of the transaction data to the transaction management module. Block 704 illustrates how to verify transaction data using the transaction management module. In the examples, the transaction management module applies a verification algorithm (hashmg) to the transaction data to create an irreversible, fixed-length hash value that can identify the specific data. The hash value allows a determination of whether subsequent transaction data maps to the hash value, but if the subsequent data is unknown, it can be difficult to reconstruct it (or any equivalent alternative). MA / t / ZUZZ / UÓ 1400 knowing the stored hash value. At least in this way, the check ensures the integrity of the transaction data. Block 706 illustrates storing the hash value using the transaction management module. In the examples, the hash value can be stored using blockchain technology. Blockchain technology creates an immutable record of transaction data so that any changes to the transaction data can be detected. Block 708 illustrates how the transaction management module determines whether one or more changes have occurred in transaction data. A change can be determined by the transaction management module by checking both the transaction data and the transaction history and storing this information on the blockchain. When a change occurs in transaction data, the transaction management module initiates a process that inputs the current transaction data and the hash of the previous transaction into the corresponding transaction data, and creates a new hash value. This new hash value can be placed on the blockchain and encoded as the transaction identifier (ID). Therefore, the change can be recorded and accessed. In the examples, a user can select the indicator or a link in a notification and view details of the changes that have occurred.Additionally, or alternatively, a user can search the public blockchain using the blockchain hash code to verify the authenticity of transaction data. The user can then compare the published transaction data with the blockchain record. Block 710 illustrates storing, through the transaction management module, a record of one or more of these changes. Block 712 illustrates notifying, via the transaction management module, at least one user or follower associated with the financial account of at least one or more of these changes. In the examples, based at least in part on the detection of deletions or changes, the transaction management module can notify users and / or followers with whom the data, account, profile, deposit, etc., has been shared or published. In the examples, the notification can be a direct notification (e.g., email, mail, phone, text, etc.) or a display of an indicator associated with the published transaction data or transaction (e.g., a marker displayed next to a transaction in a transaction list for a financial account presented through the user interface). At least due to the data monitoring performed by the transaction management module, the module can generate a linked certificate of authenticity that verifies the accuracy, truthfulness, and / or integrity of the published transaction data compared to the transaction data originally obtained from the financial institution. The certificate can be generated to certify specific transactions or provided for all accounts or profiles. It can be provided to individual users or entities upon request or published along with the transaction data. The certificate can be updated, or a new certificate can be generated, periodically or upon receiving an indication that new or changed transaction data exists. In additional or alternative examples, the transaction management module may generate MA / t / ZUZZ / UÓ 1400 transparency ratings or levels for entities, users, accounts, profiles, etc. For example, transparency ratings can be objectively determined based at least on the percentage of all associated accounts or total transaction data being published. The transaction management module can generate ratings in numerical form (e.g., 85% transparent, 68% transparent, etc.), grades (e.g., A, B, C, D, F), categories (e.g., gold, silver, bronze, etc.), and so on. A graphic icon associated with the rating can be displayed alongside transaction data, a profile, a transaction management account, a financial account, etc. The reasons for the rating can also be selected. Transaction data publication In at least one application, the transaction management module may cause transaction data to be shared and / or published. The shared or published data may be associated with one or more financial accounts, one or more thematic deposits, and / or all or part of the financial profile itself, whether that profile is a business profile for a business with which the user is associated, or a personal or entity profile. The account(s), profile(s), or thematic deposit(s) from the plurality of thematic deposits may be published in such a way that at least a subset of the corresponding transaction data may be accessible to multiple users through one or more user accounts, accessible to multiple followers, or accessible to subsets or the entire public. In some examples, an individual may publish some data without having a user account with the transaction management platform. A profile may include one or more identifying information about the associated entity, an overview of transaction data and trends, a list of an entity's transactions, and / or the thematic deposits themselves (which also incorporate financial accounts). A user can grant different permissions to followers to at least one of the following: view, follow, share, comment, express feelings, share, save, classify, or filter transaction information on individual transactions that are shared or posted, or the financial accounts from which the transaction data is posted, or the entity. In order to access the published information, a follower may be required to have their own global account with the transaction management platform, the financial social network, or, alternatively, the follower may not need to have an account with any (for example, when the published information was made public). Publishing financial information can make transaction data accessible to followers and available for them to analyze, critique, or share, thereby increasing the entity's financial transparency and transaction data. For example, a non-profit organization may wish or be required to publish financial activities and data to increase transparency. In some examples, the transaction management module may apply different permission levels to published transaction data followers. Permission levels can define which IVIA / t / ZUZZ / UÓ I4ÓD transaction data and / or the granularity of the transaction data, which a follower can access, view, share, edit, etc. The transaction management module can assign permission levels to followers by applying rules (or implementing user requests) to classify followers based, at least in part, on their characteristics. In the examples, these characteristics can be based, at least in part, on one or more profile details from a follower's profile on the transaction management platform and / or the financial social network, and / or publicly available information, other information provided by the follower to the transaction management platform, information provided by the authorized user, or information provided by the entity. Additionally, or alternatively, these characteristics and / or permission levels can be entered by a user. In the examples, the transaction management module can apply rules (or implement user requests) to classify followers by their relationship to the entity or user (e.g., board member, employee, management, shareholder, etc.). A follower can be classified into multiple classes (e.g., shareholder and employee) and can be classified into different classes for different entities / users. Each class can be associated with a permission level regarding transaction data (e.g., through rules, a permission matrix, etc.). In one example, a board member is assigned a high permission level that grants them full access to all transaction data published by the user, down to the most granular level.In the example, a member of the public is assigned the lowest permission level, and this level grants access only to summary information based on categories, as described above. For example, the lowest permission level might be configured to only allow viewing a dollar amount for an entity's total monthly expenses, and not the individual transactions that comprise that amount. In another example, a church is the entity. In the example, the church is involved in three legal disputes. Permissions are set up so that (1) the pastor and the church finance committee can see all transactions and other information for legal fees, but (2) church members can only see summary data regarding legal fees (e.g., how much is spent in total on legal fees, but not details about a particular dispute, such as how much was paid to a certain attorney or the name of the legal fee subcategory that would identify a member as the plaintiff). A follower can request permissions higher than those currently assigned to them. In the examples, the transaction management module receives the request for increased permissions, notifies the user of the request, receives the user's response, and applies changes to the permissions or permission level for the follower if the request is approved. The transaction management module can change or override classes and permissions based on user requests, profile changes, etc. Additionally, or alternatively, the transaction management module can grant certain followers permissions to modify additional information associated with transaction data. For example, a follower can be allowed to change a payee's description. IVIA / t / ZUZZ / UÓ 1400 or change a transaction categorization. However, modifying the underlying raw transaction data may trigger one or more of the consequences described above (e.g., notification, flagging, blockchain change, etc.). By classifying both followers and transactions, the techniques described herein allow raw transaction data to be processed differently by different people. An entity can be transparent about its finances to everyone, but customize the granularity of the transaction data presented, depending on the financial account and the follower. Provide additional information about changes to transaction data Figure 8 is a flowchart that illustrates an exemplary 800 process for providing a user interface that includes information about changes to transaction data, as described herein. Block 802 illustrates providing, through the financial social module for display on a tracker device, a user interface that includes a notification of one or more changes to transaction data associated with a financial account and one or more options for a tracker associated with the financial account to request additional information regarding at least one of those changes. The financial social module can provide the user interface on a tracker device. In the examples, the changes can be detected in a process illustrated in Figure 7 and its associated description. The transaction management module can transmit information about changes to transaction data to the financial social module. Based at least in part on this information, the financial social module can provide a user interface that includes a notification of one or more of those changes. Block 804 will receive, through the social and financial module, an indication of a selection of at least one or more of these options to request additional information. Block 806 illustrates providing, through the social finance module for presentation in the user interface or another user interface, at least some of the requested additional information. In the examples, the additional information may include one or more identities of the person who made the change, the amount of the change (e.g., in dollars, percentage, etc.), the date of the change, a history of changes to a transaction or transaction data, etc., a reason for the change, etc. In the examples, the additional information provided by the social finance module may be based, at least in part, on information that the social finance module receives from the transaction management module. The information provided by the transaction management module may be based, at least in part, on the identity of the follower.As discussed earlier, the transaction management module can assign different permission levels to different followers based, at least in part, on the followers' characteristics. In the examples, the transaction management module can apply rules (or implement user requests) to classify followers by their relationship to the entity or user associated with the financial account. Each class can be associated with a permission level regarding transaction data. In one example, the lowest permission level might be configured to only be able to see the dollar amount of a change detected in a transaction, while the highest permission level might be configured to be able to receive additional information, including one or more of the dollar amount of the change, the reason for the change, the identity of the person changing the data, and so on. Use collective intelligence on transactions In the examples, the transaction management module allows users to share or publish transaction data on one or more financial social networks that enable social collaboration regarding transactions. In the examples, followers can follow a financial account, a transaction management platform account, a thematic deposit, and / or one or more transactions; share information about the published transaction data with others; post a comment regarding the published transaction data; and / or indicate approval (or “like”) to the published transaction data, etc. In the examples, the transaction management module publishes follower reactions so that users, entities, and other followers of the platform can see them. In other examples, when transaction data is published publicly, audience reactions may be available to all members of the audience. Contributions gathered through social collaboration can create collective intelligence for the user or entity. This collective intelligence can help entities identify transactions (or areas, accounts, or categories of transactions) that may require more careful attention or financial management. For example, if a threshold number of followers indicates disapproval of a certain transaction or category of transactions, the transaction management module can notify the entity. By allowing different classes of followers and stakeholders to react to transaction data through social collaboration, collective intelligence can detect aberrations in transaction data (e.g., high spending, strange buying patterns, etc.) that might be missed by an independently acting financial controller or auditor. Reactions to transaction data can be fed into a machine learning algorithm to identify and flag spending aberrations and / or trends. In at least one example, a data model can be trained using machine learning mechanisms where the input data refers to historical transaction patterns and characteristics. The input data may include descriptive data indicative of characteristics and trends in historical transactions. The data model can be trained using supervised learning algorithms (e.g., artificial neural networks, Bayesian statistics, support vector machines, decision trees, classifiers, k-nearest neighbor, etc.) or unsupervised learning algorithms (e.g., artificial neural networks, association rule learning, hierarchical clustering, group analysis, etc.).), semi-supervised learning algorithms, algorithms. MA / 1400 deep learning, etc. For a particular transaction (or set of transactions), a trained data model can produce a similarity score indicative of whether the particular transaction (or set of transactions) is aberrant. Automatic identification of transaction aberrations and / or trends increases the value to transaction data followers. As part of training the data model(s), the transaction management module may weight follower reactions based at least in part on the follower's reputation, credibility, and / or experience. This weighting may be based at least in part on a reputation score and / or credibility score assigned by the transaction management module to followers who are reacting (e.g., commenting, expressing disapproval, etc.). The reputation score and / or credibility score may be based at least in part on a user profile, a history of reactions to other published transaction data, publicly available information about the follower, or third-party validation of the person's credentials (e.g., accreditation by an organization).For example, the transaction management module may assign a higher weight to a follower who has accounting experience than to a reviewer who does not. Additionally or alternatively, the transaction management module may use a machine learning algorithm to generate an importance score for discussions about published transaction data, based at least in part on factors including one or more of the number of comments, commenters' reputation scores, comment recency, comment length, etc. The transaction management module may decide to publish a discussion on a user dashboard or other user interface or forum if the importance score is above a threshold score and / or if the discussion content is determined to be of interest to the user. User interfaces Figures 9 to 11 illustrate examples of a financial social network that provides information regarding the financial account(s) transactions of an entity. Figure 9 illustrates an example of a 900 user interface (UI) that provides information regarding an entity's transaction categories, as described herein. Figure 9 is a UI presented by the financial social network that provides graphic icons for individual transaction categories. For example, graphic icon 902 represents the transaction category “ATM / Cash Spending” and indicates $1,460.41 USD of transaction activity over a period of time (not shown). Other graphic icons presented in the example of the 900 UI include those for the categories “Public Transportation,” “Restaurants and Bars,” “Groceries,” etc. Transactions are retrieved from a 904 entity financial account (“Evolving Caravan”).The Ul 900 features graphic icons (top right corner of the Ul) that, when selected, allow the page to be shared to external social media sites (e.g., Facebook™, Twitter™, Linkln™, etc.) to allow information from the Ul 900 or other information associated with the entity to be shared to the Ul / web page. Figure 10 illustrates a sample U that provides a list of transactions and information MA / t / ZUZZ / UÓ 1400 associated for a category of the transaction categories illustrated in Figure 9, as described herein. Graphic icon 1002 lists the category name, “ATM / Cash Spending,” which corresponds to graphic icon 902 in Figure 9. Transactions in this category are listed in UL 1000. Transaction 1004, listed at the top, is “ATM - Porto” and includes the amount (USD 66.90) and date (July 16, 2018). UL 1000 also displays the accounts, tags, and / or categories associated with transaction 1004 (“Cash Account,” “ATM / Cash Spending,” “EC Europe - Porto”), which can be shown in different colors. Above the transaction list are tabs for “Transactions” (the active tab), “Trends,” and “Documents.” Selecting Trends displays aggregate and trend intelligence for transactions associated with the “ATM / Cash Spending” category.The graphic icon displayed on the left side of transaction 1004 can be selected to display transaction details for that transaction, as illustrated in Figure 11. The graphic icon can be displayed in a color (for example, red). As described earlier, the transaction management module(s) can generate and display information related to how many (and which) transactions occurred within a given time period (for example, a month, a year, etc.), how many transactions fall into a specific category (for example, 100 transactions over $1,000, 2 international transactions, etc.), and so on. The “Documents” tab, if selected, can display electronic documents associated with the quantity automatically or manually (for example, by an entity, user, tracker, etc.).The Ul 1000 also includes a graphic icon representing "Balance" which can provide balance movements over a period (e.g., current month). Figure 11 illustrates a sample UL 1100 form providing details regarding a transaction (transaction 1004) from the list of transactions illustrated in Figure 10. Figure 11 provides the transaction details for transaction 1004, “ATM - Porto,” for -$66.90 on July 16, 2018. The UL 1100 indicates that the account for the transaction is “Cash Account,” the description is “ATM - Porto,” the category is “ATM / Cash Expenditure,” and the date is July 16, 2018. In the upper left corner of the UL 1100, there is a label that reads, “Manual Transactions.” This may indicate that the transaction was entered manually by a user. Other transactions might indicate “Automatic Transaction,” “Direct Load Transaction,” or similar, demonstrating that the transaction was obtained from the financial institution rather than a manual user entry.The right-hand block of UL 1100 lists “Labels” (e.g., “EC Europe - Porto”) and “Attachments” (neither of which are shown in UL 1100). An icon may be displayed adjacent to the financial account name to represent that account (e.g., a different icon may be used for credit card transactions, transfers, etc.). Synchronization API Figure 12 illustrates a flowchart that illustrates an exemplary process for incoming data flow associated with a synchronization service. In the illustrated example, a customer can submit a request to a website associated with the MA / t / ZUZZ / UÓ 1400 transaction management platform. The request can be passed to a synchronization service plugin, from the synchronization service to a load balancer, then to an external synchronization service API. The external API sends a request to an internal API of the synchronization service. A firewall may exist between the external and internal APIs. The firewall ensures compliance with regulatory requirements to protect financial transaction data by isolating the transaction management module's process start from the end of the process. External communications are directed to the external API, and the external API communicates with the internal API. The internal API can store account credentials and execute jobs, and it can communicate with a crawler to obtain information from financial institutions (e.g., banks, blockchains, etc.) via a transparent proxy. The internal API can queue requests and process them according to the queue to perform actions requested by users. The crawler connects to financial institutions via APIs or by extracting data from the web. The crawler can use financial institution-specific business logic to collect financial transaction data. The crawler can extract a queue from the caller, and different workers can process the queue depending on their work site (e.g., internal to the transaction management module; external financial data processing). The crawler may contain core logic with instructions necessary to consume data from external sources (e.g., financial institutions) in conjunction with external source-specific language code. The tracker transmits transaction data to the internal API. The internal API can process raw transaction data, including removing duplicate data. Then, the internal API can send the processed transaction data to the external API. The external API can filter transaction data and send it back to the client via connectors, presenting it through the client's website. The external API can also transmit web hooks through a transparent proxy. The external API can add all requests to a queue (an external API queue). The external API can process work in the external API queue and pass commands to the internal API. The external API can send a notification to a user if a request fails. In the examples, the internal API can instruct the crawler to retrieve the most recent transaction data for an account. The crawler can connect to the financial account using an authorization token, retrieve the transaction data, and send the transaction data to the internal API. The internal API can persist the transaction data. An internal plugin (e.g., "Synchronization Plugin") to communicate with a load balancer to scale the APIs. Conclusion The subject matter here proposes the integration of at least the aforementioned characteristics ML / t / ZUZZ / UÓ 1400 was previously described as a fluid and convenient mechanism for publishing transaction data. Regarding the problems previously identified with conventional systems and methods, the software applications themselves become an active and cooperative component of the process, rather than the object of it. Furthermore, the description above is directed at devices and applications related to transaction data management. However, it is understood that the technology can be extended to any device and application. Moreover, the techniques described herein can be configured to operate independently of the type of user device, server device, computer network, and environment. The techniques described herein can be configured to operate in both real-time / online and offline modes. While the disclosure mentioned above refers to user interactions with a user interface (UI) presented via a device screen, the UI can be presented through any input / output device. For example, the UI can be delivered through a speaker, an augmented reality projector, and so on. Furthermore, while the disclosure mentioned above refers to a user or viewer interacting with the UI via a selectable control, in additional or alternative examples, the user or viewer may indicate a selection through spoken or other input. The foregoing is merely illustrative of the principles of this disclosure, and various modifications may be made by those experienced in the field without departing from the scope of the disclosure. The examples described above are presented for illustrative purposes and not to limit its scope. This disclosure may also take many forms other than those explicitly described herein. Accordingly, it is emphasized that this disclosure is not limited to the methods, systems, and apparatus explicitly disclosed, but is intended to include variations and modifications thereof, which are within the substance of the following claims. As a further example, variations in apparatus or process limitations (e.g., dimensions, configurations, components, order of process steps, etc.) can be made to further optimize the structures, devices, and methods provided, as shown and described herein. In any event, the structures, devices, and associated methods described herein have many applications. Accordingly, the disclosed subject matter should not be limited to any single example described herein, but rather should be expanded in extent and scope in accordance with the appended claims. Several instructions, methods, and techniques described herein can be considered within the general context of computer-executable instructions, such as program modules stored on computer-readable media and executed by the processor(s) described herein. Program modules typically include routines, programs, objects, components, data structures, and so on, to accomplish particular tasks or implement specific abstract data types. These program modules, and similar ones, can be executed as native code or downloaded and run, such as in a virtual machine or other just-in-time compilation runtime environment. The functionality of program modules can generally be combined or distributed as desired across various implementations.An implementation of these modules and techniques can be stored on computer storage media or transmitted through some form of communication medium. Although the modalities have been described in language specific to structural characteristics and / or methodological actions, it should be understood that the disclosure is not necessarily limited to the specific characteristics or actions described. Rather, the specific characteristics and actions are disclosed herein as illustrative ways of implementing the modalities. Exemplary clauses Clause 1. A method, implemented by one or more servers of a transaction management platform, comprising: to request, from a financial institution, transaction data that corresponds to one or more financial transactions associated with a financial account of an entity; receive the transaction data from the financial institution; store transaction data and an association of the transaction data with a user account of an authorized user of the transaction management platform; and based at least in part on receiving an instruction from the authorized user, publish the transaction data to create published transaction data, wherein publication comprises allowing access to at least a portion of the transaction data. Clause 2. The method in accordance with clause 1, which further comprises receiving transaction data from at least one bank account, cash account, investment account, or digital wallet. Clause 3. The method in accordance with any one or more of clauses 1 to 2, which further comprises: receive user credentials for the authorized user's user account; receive a jurisdiction of the authorized user's financial account; and select, based at least in part on the jurisdiction, one of the transaction management platform or a third party as an interface to the financial institution, from at least the authorized user's financial account credentials and a request for transaction data. Clause 4. The method in accordance with any or more of clauses 1 to 3, further comprising providing a notification with respect to the published transaction data to at least one follower of the published transaction data, wherein the notification comprises at least one of an email, a text message, or a graphic icon on a screen of the published transaction data. Clause 5. The method in accordance with any or more of clauses 1 to 4, further comprising allowing, at least in part by the application of permission rules, a first follower of the published transaction data to see a first portion of the published transaction data and a second follower of the published transaction data to see a second portion of the data IVIA / t / ZUZZ / UÓ 1400 transaction published. Clause 6. The method in accordance with clause 5, wherein the permission rules are based at least in part on the preferences of the authorized user, characteristics of the first follower, and characteristics of the second follower. Clause 7. The method in accordance with clause 6, wherein the characteristics are based at least in part on one or more of the profile information of the first or second follower's profile on the transaction management platform or financial social network, publicly available information, other information provided by the first or second follower to the transaction management platform or financial social network, information provided by the authorized user, or information provided by the entity. Clause 8. The method in accordance with any one or more of clauses 1 to 7, which further comprises: Based at least in part on the receipt of transaction data, apply a verification algorithm to the transaction data, creating verified transaction data; store the verified transaction data; Monitor verified transaction data to determine if the verified transaction data has changed; and based at least in part on determining that at least some of the verified transaction data has changed, present an indication associated with the published transaction data or notify the followers. Clause 9. The method in accordance with any or more of clauses 5, 6 or 7, wherein the permission rules determine permissions comprising at least one of viewing transaction data, commenting on transaction data, sharing transaction data, or editing metadata of transaction data. Clause 10. The method in accordance with any or more of clauses 1 to 9, further comprising assigning a transaction corresponding to the transaction data to one or more categories based at least in part on one or more of a comparison of the transaction data with one or more predefined categorization rules or receiving a selection of one or more of such categories from a device associated with the authorized user. Clause 11. The method in accordance with clause 10, which further comprises: add at least one or more of these transactions based at least in part on one or more of these categories; and cause the presentation of one or more of these transactions based at least in part on one or more of these categories. Clause 12. The method in accordance with any one or more of clauses 1 to 11, which further comprises: to determine, based at least in part on data indicating the follower's interaction with the published transaction data, a follower sentiment corresponding to one or more transactions; and convey to the authorized user an indication of the sentiment. Clause 13. The method in accordance with Clause 12, wherein the follower's interaction comprises at least one of a number of comments by the follower, a comment content by the follower, an indication of approval or disapproval, sharing transaction data posted by the follower, or subscribing to updates of posted transaction data. Clause 14. The method in accordance with any or more of clauses 12 or 13, further comprising determining a level of financial transparency of the entity based at least in part on a percentage of transactions in a financial account that are published or a percentage of the entity's financial accounts for which transaction data are published by means of the transaction management platform. Clause 15. One or more computer-readable media having computer-readable instructions thereon that, when executed by one or more processors, cause one or more of those processors to carry out a method in accordance with one or more of clauses 1 to 14. Clause 16. A system comprising: one or more processors; and one or more computer-readable media including computer-readable instructions that, when executed by one or more of such processors, configure the system to carry out a method in accordance with one or more of clauses 1 to 14. Clause 17. A system implemented by one or more servers of a transaction management platform comprising, wherein the system comprises: one or more processors; one or more computer-readable media that store instructions which, when executed by one or more of said processors, cause the system to perform operations comprising: trigger the presentation of a first user interface (Ul), where the first Ul receives, from a user of a transaction management platform, user credentials and a jurisdiction of a financial account of an entity; Select, based at least in part on the authentication of user credentials and jurisdiction, one of the transaction management platform or a third party as an interface to a financial institution associated with the financial account; to trigger the presentation, through the interface, of a second Ul that receives a selection from the user of the financial institution and the user's financial account credentials; transmit, through the interface to the financial institution, the financial account credentials and an authorization token for the financial institution; receive the authorization token through the interface and the financial institution; store the authorization token through the interface; MA / t / ZUZZ / UÓ transmit, through the interface to the financial institution, the authorization token and a request for transaction data associated with the financial account; to receive, through the interface and the financial institution, the transaction data; transmit, through the interface to a synchronization application programming interface (API) associated with one or more of said servers, the transaction data; normalize transaction data using the synchronization API; generate an authentication token using the synchronization API; to store, by means of one or more of said servers, the transaction data and the authentication token; and to publish the transaction data to create published transaction data, wherein publishing the transaction data comprises allowing access to at least a portion of the transaction data. Clause 18. The system in accordance with clause 17, further comprising providing a notification with respect to the published transaction data to at least one follower of the published transaction data, wherein the notification comprises at least one of an email, a text message, or a graphic icon on a screen of the published transaction data. Clause 19. The system in accordance with clause 17, further comprising allowing, at least in part by the application of permission rules, a first follower of the published transaction data to see a first portion of the published transaction data and a second follower of the published transaction data to see a second portion of the published transaction data, wherein the first portion and the second portion overlap at least partially. Clause 20. The system in accordance with clause 17, which further comprises determining a level of financial transparency of the entity based at least in part on a percentage of transactions in the financial account that are published or a percentage of the entity's accounts for which transaction data are published by means of the transaction management platform.

Claims

1. A method, implemented by one or more servers of a transaction management platform, comprising: requesting, from a financial institution, transaction data relating to one or more financial transactions associated with a financial account of an entity; receiving, from the financial institution, the transaction data; storing the transaction data and an association of the transaction data with a user account of an authorized user of the transaction management platform; and based at least in part on receiving an instruction from the authorized user, publishing the transaction data to create published transaction data, wherein publishing comprises allowing access to at least a portion of the transaction data.

2. The method according to claim 1, further comprising receiving transaction data from at least one bank account, cash account, investment account, or digital wallet.

3. The method according to claim 1, further comprising: receiving user credentials for the authorized user's user account; receiving a jurisdiction from the authorized user's financial account; and selecting, based at least in part on the jurisdiction, one of the transaction management platform or a third party as an interface to the financial institution, from at least the authorized user's financial account credentials and a request for transaction data.

4. The method according to claim 1, further comprising providing a notification regarding the published transaction data to at least one follower of the published transaction data, wherein the notification comprises at least one of an email, a text message, or a graphic icon on a screen of the published transaction data.

5. The method according to claim 1, further comprising enabling, at least in part by applying permission rules, a first follower of the published transaction data to see a first portion of the published transaction data and a second follower of the published transaction data to see a second portion of the published transaction data.

6. The method according to claim 5, wherein the permission rules are based at least in part on preferences of the authorized user, characteristics of the first follower, and characteristics of the second follower.

7. The method according to claim 6, wherein the features are based at least in part on one or more profile information from a profile of the first or second follower on the transaction management platform or a financial social network, publicly available information, other information provided by the first or second follower to the transaction management platform or the financial social network, information provided by the authorized user, or information provided by the entity. IVIA / t / ZUZZ / UÓ 1400 8. The method according to claim 1, further comprising: based at least in part on the receipt of transaction data, applying a verification algorithm to the transaction data, creating verified transaction data; storing the verified transaction data; monitoring the verified transaction data to determine whether the verified transaction data has changed; and based at least in part on determining that at least some of the verified transaction data has changed, presenting an indication associated with the published transaction data or notifying the followers.

9. The method according to claim 5, wherein the permission rules determine permissions comprising at least one of viewing transaction data, commenting on transaction data, sharing transaction data, or editing transaction data metadata.

10. The method according to claim 1, further comprising assigning a transaction corresponding to the transaction data to one or more categories based at least in part on one or more of a comparison of the transaction data with one or more predefined categorization rules or receiving a selection of one or more of such categories from a device associated with the authorized user.

11. The method according to claim 10 further comprising: aggregating at least one or more of said transactions based at least in part on one or more of said categories; and causing the presentation of one or more of said transactions based at least in part on one or more of said categories.

12. The method according to any of claims 1 to 11, further comprising: determining, based at least in part on data indicating a follower's interaction with published transaction data, a follower sentiment corresponding to one or more transactions; and transmitting, to the authorized user, an indication of the sentiment.

13. The method according to claim 12, wherein the follower interaction comprises at least one of a number of comments by the follower, a comment content by the follower, an indication of approval or disapproval, sharing the transaction data posted by the follower, or subscribing to updates of the posted transaction data.

14. The method according to claim 12, further comprising determining a level of financial transparency of the entity based at least in part on a percentage of transactions in a financial account that are published or a percentage of the entity's financial accounts for which transaction data are published by means of the transaction management platform.

15. One or more computer-readable media having computer-readable instructions thereon that, when executed by one or more processors, cause one or more of said processors to carry out a method according to any one of claims 1 to 14.

16. A system comprising: one or more processors; and one or more computer-readable media including computer-readable instructions that, when executed by one or more of said processors, configure the system to carry out a method according to any one of claims 1 to 14.

17. A system implemented by one or more servers of a transaction management platform comprising, wherein the system comprises: one or more processors; one or more computer-readable media that store instructions that, when executed by one or more of said processors, cause the system to perform operations comprising: causing the presentation of a first user interface (Ul), wherein the first Ul receives, from a user of a transaction management platform, user credentials and a jurisdiction of a financial account of an entity; selecting, based at least in part on the authentication of the user credentials and the jurisdiction, one of the transaction management platform or a third party as an interface to a financial institution associated with the financial account;trigger the presentation, through the interface, of a second UI that receives a selection of the user from the financial institution and the user's financial account credentials; transmit, through the interface to the financial institution, the financial account credentials and an authorization token for the financial institution; receive, through the interface and from the financial institution, the authorization token; store, through the interface, the authorization token; transmit, through the interface and to the financial institution, the authorization token and a request for transaction data associated with the financial account; receive, through the interface and from the financial institution, the transaction data; transmit, through the interface to a synchronization application programming interface (API) associated with one or more of said servers, the transaction data;normalize transaction data using the synchronization API; generate an authentication token using the synchronization API; store the transaction data and the authentication token on one or more of these servers; and publish the transaction data to create published transaction data, wherein publishing the transaction data comprises allowing access to at least a portion of the transaction data.

18. The system according to claim 17, further comprising providing a notification regarding the published transaction data to at least one follower of the published transaction data, wherein the notification comprises at least one of an email, a text message, or a graphic icon on a screen of the published transaction data.

19. The system according to claim 17, further comprising enabling, at least in part by the application of permission rules, a first follower of the published transaction data to see a first portion of the published transaction data and a second follower of the published transaction data to see a second portion of the published transaction data, wherein the first portion and the second portion overlap at least partially.

20. The system according to claim 17, further comprising determining a level of financial transparency of the entity based at least in part on a percentage of transactions in the financial account that are published or a percentage of the entity's accounts for which transaction data are published by means of the transaction management platform.