In some implementations, a verification system may receive, from a user device, a request to validate an account. The verification system may initiate a microdeposit using an electronic rail, and the microdeposit may be associated with a human-readable description. The verification system may receive, from the user device, an indication of the human-readable description associated with the microdeposit. The verification system may therefore validate the account based on the indication.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
Systems and methods for data parsing are disclosed. In one aspect, a method of parsing raw data associated with one or more transactions involves receiving a text string including raw data for a transaction, matching the text string to a plurality of locations within a location corpus to extract location information from the text string, and identifying a candidate entity from the text string based on a similarity score with respect to a plurality of entities within an entity corpus. The method further involves in response to the similarity score of the identified candidate entity being less than a threshold score, generating entity information using the tokens indicative of entity information, and generating normalized transaction data including the extracted location information and one of the identified candidate entity or the generated entity information.
A user account evaluation system is disclosed for evaluating risk associated with a user account. The system may obtain user account data associated with many user accounts, select a statistically significant subset of the user accounts, and then process (e.g., to determine types of the user accounts, etc.) and analyze the subset of user accounts to generate a plurality of evaluation models. When a new user account is accessed by the system, user account data may be obtained for the new user account, and the new user account may be evaluated based on the plurality of evaluation models. Accordingly, a plurality of evaluation parameter scores may be generated for the new user account, each of which may indicate an amount of risk associated with the user account. Some embodiments of the present disclosure may include machine learning and/or artificial intelligence methods to improve evaluation of the user accounts.
In some implementations, a verification device may generate a first set of radio buttons associated with a first verification procedure and provide the first set of radio buttons in an area associated with a verification template. The verification device may receive a selection of a configuration for the first verification procedure using the first set of radio buttons. The verification device may generate a second set of radio buttons associated with a second verification procedure and provide the second set of radio buttons in the area associated with the verification template. The verification device may receive a selection of a configuration for the second verification procedure using the second set of radio buttons. Accordingly, the verification device may generate instructions for generating a set of user interfaces based on the selection of the configuration for the first verification procedure and the selection of the configuration for the second verification procedure.
G06F 3/0481 - Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
G06F 3/0482 - Interaction with lists of selectable items, e.g. menus
G06F 8/38 - Creation or generation of source code for implementing user interfaces
G06F 9/448 - Execution paradigms, e.g. implementations of programming paradigms
G06F 9/451 - Execution arrangements for user interfaces
G06F 21/32 - User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
G06F 21/36 - User authentication by graphic or iconic representation
In some implementations, a classification system may receive credentials associated with a data source and may receive, from the data source and using the credentials, a set of structured data including input events and output events. The classification system may filter the set of structured data by applying a first set of rules to generate a filtered set of structured data and may convert the filtered set of structured data to one or more numerical vectors, where a vector space associated with the one or more numerical vectors is infinite-dimensional. The classification system may further cluster the one or more numerical vectors using a first machine learning model to generate one or more clusters. Accordingly, the classification system may determine one or more classifications based on the set of structured data, each of the one or more classifications being associated with a corresponding frequency and a corresponding category.
In some implementations, a verification system generates visual regions, each associated with a verification rule and including visual elements for defining a type of user information and a type of matching criterion. These elements include at least one pair of visual selectors: a first selector for user information and a second selector for matching criteria. The system dynamically modifies the verification rule based on real-time interaction with these elements and determines user verification by applying received input to the modified rule. Features include drag-and-drop components, customizable matching thresholds, color-coded rule status indicators, and the management of verification rules through addition, deletion, and modification of visual selectors.
G06F 3/0481 - Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
G06F 3/0482 - Interaction with lists of selectable items, e.g. menus
G06F 8/38 - Creation or generation of source code for implementing user interfaces
G06F 9/451 - Execution arrangements for user interfaces
7.
SYSTEM AND METHOD FOR MAINTAINING INTERNET ANONYMITY VIA CLIENT FINGERPRINT
A system and method for altering client fingerprint that includes editing data components of network communication from a client device to a server, which comprises editing network protocol data from the client during negotiation of a cryptographic protocol; selectively enabling access to library components specified in the edited client network protocol data; and sending a client communication to the server using the edited client network protocol data.
A system and method for aggregating account data, and more specifically, a system and method for aggregation of financial account data that provides enhanced privacy and security protections to a user by enabling the user to maintain custody of his or her login credentials. A syncing agent in coordination with a system add-on coordinates log-in to a remote system and storage of session information. Syncing agent utilizes the session agent to retrieve additional information on behalf of the user or perform other tasks on the remote server.
G06F 16/27 - Replication, distribution or synchronisation of data between databases or within a distributed database systemDistributed database system architectures therefor
A system and method for cloud management of user interactions on a client device comprising: initiating, in response to an initiation request of a client application, processing of a workflow configuration with an initial session state, wherein the workflow is a data model of a graph of nodes connected with directed edges, where the nodes include a set of node types that includes at least a pane node; iteratively processing the workflow configuration, initially using the initial session state, and thereby generating rendered panes for use in a user interaction flow of a client application, which comprises: following a next edge of the workflow configuration to determine a next workflow node, processing the next workflow node, which comprises, when the next workflow node is a pane node, rendering the pane node into a rendered pane, and sending the rendered panes to the client device.
A system and method that includes receiving a client data packet from network traffic with a client device; extracting a set of packet components from the client data packet; generating a client fingerprint from the set of packet components; assigning a client type to the network traffic using the client fingerprint; and optionally filtering the network traffic of the client device based at least in part on the client type.
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
H04L 9/06 - Arrangements for secret or secure communicationsNetwork security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
A system and method for secure permissioning of access to user accounts, including secure distribution of aggregated user account data can include generating a financial report based on account information associated with one or more user accounts; receiving a financial report request for the financial report of the user account, wherein the financial report request is identified as being received from a third-party system; generating an audit report token associated with the financial report; sharing the audit token with the first third-party system in response to the financial report request; and providing the first third-party system account access to the financial report through the report token, where the audit report token can be shared with a second third-party system and provided by the second third-party system in order to confirm authorization to the report and integrity of the report.
In some implementations, a validation device may receive a set of rules associated with requests to and responses from a set of application programming interfaces (APIs). The validation device may transmit, to the set of APIs, a plurality of requests based on the set of rules. The validation device may receive, from the set of APIs, a plurality of responses corresponding to the plurality of requests. The validation device may verify the plurality of responses against the set of rules. The validation device may transmit, to a user device, instructions for a user interface indicating one or more results from verifying the plurality of responses against the set of rules.
In some implementations, a tokenizer may receive, from a registered device, an authorization request for account information, in a format associated with a network, to use for an event. The tokenizer may generate a token, transparent to the format associated with the network and based on the account information, where the token expires after a single use for the event. The tokenizer may transmit the token to the registered device in response to the authorization request. The tokenizer may transmit an indication associated with the token to a processing device included in the network.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
Systems and methods for programmatic access of external financial service systems. An application proxy instance is created that simulates an application of an external financial service system. A normalized account request is received for financial data of the external financial service system for a specified account. The normalized account request is provided by an external financial application system by using a financial data API of the financial platform system. Responsive to the normalized account request, communication is negotiated with the external financial service system by using the application proxy instance to access the requested financial data from the external financial service system by using a proprietary Application Programming Interface (API) of the external financial service system. The financial data is provided to the external financial application system as a response to the normalized account request.
In some implementations, an enrichment engine may receive a first entry. The enrichment engine may generate a normalized first entry by using subword tokenization of the first entry. The enrichment engine may execute a plurality of searches concurrently, including: a first search configured to map a portion of the normalized first entry to a first result using regular expressions and fuzzy matching, a second search configured to provide the normalized first entry to a machine learning model in order to receive a second result, and a third search configured to map a vectorized version of the normalized first entry to a third result in a vector database. The enrichment engine may determine a selected result from the first result based on the first search, the second result based on the second search, or the third result based on the third search. The enrichment engine may return the selected result.
Systems and techniques are disclosed for accessing accounts associated with a user and estimating a value of an attribute associated with the user based upon the retrieved account information. Transaction data associated with an account at an external user account system is received. The transactions are categorized into transaction groups. For each transaction group, a confidence value that the group is associated with the attribute is estimated, based at least in part upon a distribution of transaction amounts for the transactions of the group over a time period associated with the group. An attribute value is estimated for each group, based at least in part upon the transaction amounts of the transaction of the group. In addition a value of the attribute for a future time period may be predicted based upon the transaction groups.
In some implementations, a data partner may transmit a first request associated with a user account and may receive a first response including an access token. The data partner may transmit a second request, that includes the access token, for a list of applications associated with the user account and may receive a second response including the list of applications. The data partner may transmit a third request, that includes the access token, for a list of activities associated with the list of applications and may receive a third response including the list of activities. The data partner may transmit a fourth request, that includes the access token, to unlink a selected application, from the list of applications, from the user account. The data partner may receive an indication that a token associated with the selected application was revoked.
A permissions management system is disclosed for enabling a user to securely authorize access to user accounts and/or securely authorize execution of transactions related to user accounts via one or more application programming interfaces (“APIs”) and/or one or more authorization mechanisms.
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
H04L 29/06 - Communication control; Communication processing characterised by a protocol
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
Systems and methods for programmatic access of a financial institution system. A normalized API request provided by an application system specifies user information corresponding to at least one account endpoint of an external financial institution system. Responsive to the request, at least one application proxy instance associated with the normalized API request is used to collect transaction information from a corresponding financial institution system by providing the financial institution system with a proprietary API request. The transaction information is included in at least one proprietary API response provided by the financial institution system. A normalized API response is generated based on the collected transaction information and provided to the application system. Each application proxy instance is constructed to simulate an application of the corresponding financial institution system on behalf of a user associated with the application proxy instance.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
21.
SYSTEM AND METHOD FOR ASSESSING A DIGITAL INTERACTION WITH A DIGITAL THIRD PARTY ACCOUNT SERVICE
A system and method for assessing digital interactions with a digital third party accounts can include receiving user account credentials for authentication with an external computing system, storing the user account credentials in association with a authentication token and communicating the authentication token to a computing device of an external application service; receiving, through a programmatic communication interface, a request that references the authentication token and digital interaction details; programmatically authenticating, using the stored user account credentials, as a user account with the external computing system and retrieving account data; processing the account data in combination with the digital interaction details and thereby generating a digital interact assessment; and initiating execution of a digital interaction based in part on the digital interaction assessment.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
22.
Predicting data availability and scheduling data pulls
In some implementations, a data aggregator may receive an indication associated with a data record. The data aggregator may apply a model to the indication to generate a prediction regarding when new information associated with the data record will be available. Based on the prediction, the data aggregator may refrain from requesting new information and may schedule a pull for new information associated with the data record for a later time. Additionally, or alternatively, the data aggregator may receive an indication associated with a plurality of data pulls that are associated with a plurality of data records and may receive an indication of a rate limit associated with a host for the plurality of data records. The data aggregator may apply rules to generate a ranking of the plurality of data pulls and may schedule the plurality of data pulls based on the ranking and the rate limit.
In some implementations, a data aggregator may receive an indication associated with a data record. The data aggregator may apply a model to the indication to generate a prediction regarding when new information associated with the data record will be available. Based on the prediction, the data aggregator may refrain from requesting new information and may schedule a pull for new information associated with the data record for a later time. Additionally, or alternatively, the data aggregator may receive an indication associated with a plurality of data pulls that are associated with a plurality of data records and may receive an indication of a rate limit associated with a host for the plurality of data records. The data aggregator may apply rules to generate a ranking of the plurality of data pulls and may schedule the plurality of data pulls based on the ranking and the rate limit.
Systems and methods for programmatic access of a financial institution system. A normalized API request provided by an application system specifies user information corresponding to at least one account endpoint of an external financial institution system. Responsive to the request, at least one application proxy instance associated with the normalized API request is used to collect transaction information from a corresponding financial institution system by providing the financial institution system with a proprietary API request that specifies at least account credentials associated with the user information. The transaction information is included in at least one proprietary API response provided by the financial institution system. A normalized API response is generated based on the collected transaction information and provided to the application system. Each application proxy instance is constructed to simulate an application of the corresponding financial institution system on behalf of a user associated with the application proxy instance.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
In some implementations, a verification system may generate a selector associated with a plurality of countries. The verification system may receive an indication of a selected country from the plurality of countries. Accordingly, the verification system may generate one or more visual regions, where each visual region is associated with a corresponding verification rule and includes at least one pair of visual selectors with a first selector associated with a type of user information and a second selector associated with a type of matching. The verification system may modify the verification rule based on interaction with the at least one pair of visual selectors included in a corresponding visual region of the one or more visual regions.
G06F 3/0481 - Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
G06F 3/0482 - Interaction with lists of selectable items, e.g. menus
G06F 8/38 - Creation or generation of source code for implementing user interfaces
G06F 9/448 - Execution paradigms, e.g. implementations of programming paradigms
G06F 9/451 - Execution arrangements for user interfaces
G06F 21/32 - User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
G06F 21/36 - User authentication by graphic or iconic representation
Systems and methods for programmatic access of external financial service systems. An application proxy instance is created that simulates an application of an external financial service system. A normalized account request is received for financial data of the external financial service system for a specified account. The normalized account request is provided by an external financial application system by using a financial data API of the financial platform system. Responsive to the normalized account request, communication is negotiated with the external financial service system by using the application proxy instance to access the requested financial data from the external financial service system by using a proprietary Application Programming Interface (API) of the external financial service system. The financial data is provided to the external financial application system as a response to the normalized account request.
Systems and methods for secure updating of allocations to user accounts are provided. In one aspect, a system includes one or more computer readable storage mediums having program instructions embodied therewith, and one or more processors configured to cause the system to identify an external institution associated with the future transfers, and initiate, based on the identified external institution, a proxy instance of a software application of the external institution to determine a set of endpoints and a set of the future transfers to the endpoints. The system is further configured to receive a request from a user to change at least one of the set of the endpoints and the set of the further transfers to the endpoints, and use the proxy instance, executing the requested change to at least one of the set of the endpoints or the set of the future transfers to the endpoints.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
28.
SYSTEM AND METHOD LINKING TO ACCOUNTS USING CREDENTIAL-LESS AUTHENTICATION
A system and method for linking to accounts using credential-less authentication that includes: within a first application context at an account-linking computing service: receiving a request to establish an account link, establishing the account link to a user account of an account service using user credentials, and receiving user identifying information of the first application context and storing the user identifying information in association with the account link; and within a second application context at the account-linking computing service: receiving user identifying information of the second application context, searching and identifying a candidate account link using the user identifying information of the second application context, verifying eligibility for access to the account link, and permitting access to the account link upon successful verification of eligibility.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
In some implementations, a classification system may receive credentials associated with a data source and may receive, from the data source and using the credentials, a set of structured data including input events and output events. The classification system may filter the set of structured data by applying a first set of rules to generate a filtered set of structured data and may convert the filtered set of structured data to one or more numerical vectors, where a vector space associated with the one or more numerical vectors is infinite-dimensional. The classification system may further cluster the one or more numerical vectors using a first machine learning model to generate one or more clusters. Accordingly, the classification system may determine one or more classifications based on the set of structured data, each of the one or more classifications being associated with a corresponding frequency and a corresponding category.
Systems and methods for programmatic access of a financial institution system. A normalized API request provided by an application system specifies user information corresponding to at least one account endpoint of an external financial institution system. Responsive to the request, at least one application proxy instance associated with the normalized API request is used to collect transaction information from a corresponding financial institution system by providing the financial institution system with a proprietary API request that specifies at least account credentials associated with the user information. The transaction information is included in at least one proprietary API response provided by the financial institution system. A normalized API response is generated based on the collected transaction information and provided to the application system. Each application proxy instance is constructed to simulate an application of the corresponding financial institution system on behalf of a user associated with the application proxy instance.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
31.
System and method for maintaining internet anonymity via client fingerprint
A system and method for altering client fingerprint that includes editing data components of network communication from a client device to a server, which comprises editing network protocol data from the client during negotiation of a cryptographic protocol; selectively enabling access to library components specified in the edited client network protocol data; and sending a client communication to the server using the edited client network protocol data.
A system and method for secure permissioning of access to user accounts, including secure distribution of aggregated user account data can include generating a financial report based on account information associated with one or more user accounts; receiving a financial report request for the financial report of the user account, wherein the financial report request is identified as being received from a third-party system; generating an audit report token associated with the financial report; sharing the audit token with the first third-party system in response to the financial report request; and providing the first third-party system account access to the financial report through the report token, where the audit report token can be shared with a second third-party system and provided by the second third-party system in order to confirm authorization to the report and integrity of the report.
Systems and methods for programmatic access of external financial service systems. An application proxy instance is created that simulates an application of an external financial service system. A normalized account request is received for financial data of the external financial service system for a specified account. The normalized account request is provided by an external financial application system by using a financial data API of the financial platform system. Responsive to the normalized account request, communication is negotiated with the external financial service system by using the application proxy instance to access the requested financial data from the external financial service system by using a proprietary Application Programming Interface (API) of the external financial service system. The financial data is provided to the external financial application system as a response to the normalized account request.
A system and method that includes receiving a client data packet from network traffic with a client device; extracting a set of packet components from the client data packet; generating a client fingerprint from the set of packet components; assigning a client type to the network traffic using the client fingerprint; and optionally filtering the network traffic of the client device based at least in part on the client type.
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
H04L 43/026 - Capturing of monitoring data using flow identification
H04L 43/028 - Capturing of monitoring data by filtering
H04L 9/06 - Arrangements for secret or secure communicationsNetwork security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
H04L 43/04 - Processing captured monitoring data, e.g. for logfile generation
35.
DATA ENRICHMENT USING NAME, LOCATION, AND IMAGE LOOKUP
In some implementations, a server may receive, from a user device and at a secure endpoint of an application programming interface, a set of structured data including a plurality of entries. The server may extract, from each entry, a corresponding partial string from a corresponding description string included in the entry, and may determine, for each partial string, a corresponding data structure in a database. The server may generate, for each entry, a standardized name and a location indicator based on the corresponding data structure, and may extract, for each data structure, an image corresponding to the data structure. Accordingly, the server may return, to the user device, a modified set of structured data including, for each entry, the standardized name, the location indicator, and the corresponding image.
In some implementations, a server may receive, from a user device, one or more credentials associated with a data source. Accordingly, the server may receive, from the data source and using the one or more credentials, a set of structured data including a plurality of entries. The server may identify at least one recurring event based on one or more entries in the plurality of entries, and may determine, for the at least one recurring event, one or more derived properties. The server may generate a data structure indicating the at least one recurring event and the one or more derived properties, and may transmit, to the user device, the generated data structure.
In some implementations, an aggregation system may receive, from a user device, a registration message. The aggregation system may receive, from a data source, an initial set of structured data. The aggregation system may receive, from the data source and periodically, updates to the initial set of structured data. The aggregation system may transmit, to the user device and via a webhook activated based on the registration message, an indication of each update. The aggregation system may generate, based on each update, a corresponding differential data structure. The aggregation system may transmit, to the user device, each corresponding differential data structure.
G06F 16/27 - Replication, distribution or synchronisation of data between databases or within a distributed database systemDistributed database system architectures therefor
A system and method for cloud management of user interactions on a client device comprising: initiating, in response to an initiation request of a client application, processing of a workflow configuration with an initial session state, wherein the workflow is a data model of a graph of nodes connected with directed edges, where the nodes include a set of node types that includes at least a pane node; iteratively processing the workflow configuration, initially using the initial session state, and thereby generating rendered panes for use in a user interaction flow of a client application, which comprises: following a next edge of the workflow configuration to determine a next workflow node, processing the next workflow node, which comprises, when the next workflow node is a pane node, rendering the pane node into a rendered pane, and sending the rendered panes to the client device.
G06F 3/00 - Input arrangements for transferring data to be processed into a form capable of being handled by the computerOutput arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
G06F 9/48 - Program initiatingProgram switching, e.g. by interrupt
Systems and methods for programmatic access of external financial service systems. An application proxy instance is created that simulates an application of an external financial service system. A normalized account request is received for financial data of the external financial service system for a specified account. The normalized account request is provided by an external financial application system by using a financial data API of the financial platform system. Responsive to the normalized account request, communication is negotiated with the external financial service system by using the application proxy instance to access the requested financial data from the external financial service system by using a proprietary Application Programming Interface (API) of the external financial service system. The financial data is provided to the external financial application system as a response to the normalized account request.
A system and method for altering client fingerprint that includes editing data components of network communication from a client device to a server, which comprises editing network protocol data from the client during negotiation of a cryptographic protocol; selectively enabling access to library components specified in the edited client network protocol data; and sending a client communication to the server using the edited client network protocol data.
In some implementations, a verification system may initiate a state machine associated with a verification for the user, the state machine being associated with a plurality of verification procedures for the user. The verification system may modify a state of the state machine associated with a subsequent procedure of the verification procedures based on an outcome associated with a preceding procedure of the verification procedures. The verification system may determine a final state of the state machine based on an outcome associated with the subsequent procedure of the verification procedures.
In some implementations, a verification device may generate a first set of radio buttons associated with a first verification procedure and provide the first set of radio buttons in an area associated with a verification template. The verification device may receive a selection of a configuration for the first verification procedure using the first set of radio buttons. The verification device may generate a second set of radio buttons associated with a second verification procedure and provide the second set of radio buttons in the area associated with the verification template. The verification device may receive a selection of a configuration for the second verification procedure using the second set of radio buttons. Accordingly, the verification device may generate instructions for generating a set of user interfaces based on the selection of the configuration for the first verification procedure and the selection of the configuration for the second verification procedure.
G06F 3/0482 - Interaction with lists of selectable items, e.g. menus
G06F 3/0481 - Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
G06F 8/38 - Creation or generation of source code for implementing user interfaces
G06F 9/451 - Execution arrangements for user interfaces
In some implementations, a verification system may receive input from a user associated with an account that already underwent a verification procedure. Accordingly, the verification system may generate at least one graphical user interface associated with a first verification operation, within the verification procedure, that is associated with a failed outcome. The verification system may perform verification of the user based on new input for the first verification operation and old input for one or more additional verification operations within the verification procedure.
Systems and techniques are disclosed for accessing accounts associated with a user and estimating a value of an attribute associated with the user based upon the retrieved account information. Transaction data associated with an account at an external user account system is received. The transactions are categorized into transaction groups. For each transaction group, a confidence value that the group is associated with the attribute is estimated, based at least in part upon a distribution of transaction amounts for the transactions of the group over a time period associated with the group. An attribute value is estimated for each group, based at least in part upon the transaction amounts of the transaction of the group. In addition a value of the attribute for a future time period may be predicted based upon the transaction groups.
In some implementations, a verification system may generate a selector associated with a plurality of countries. The verification system may receive an indication of a selected country from the plurality of countries. Accordingly, the verification system may generate one or more visual regions, where each visual region is associated with a corresponding verification rule and includes at least one pair of visual selectors with a first selector associated with a type of user information and a second selector associated with a type of matching. The verification system may modify the verification rule based on interaction with the at least one pair of visual selectors included in a corresponding visual region of the one or more visual regions.
A system and method for verifying account ownership using verified deposits. An ACH verification platform may recognize or detect a verification process involving micro deposits. A verification platform may receive and store user login, initiate the deposits, and monitor the user's account to verify that posting of the deposits was successful. In embodiments, a dedicated web form or portal may be provided for receiving verification information.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment
G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
H04L 29/06 - Communication control; Communication processing characterised by a protocol
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
A system and method for aggregating account data, and more specifically, a system and method for aggregation of financial account data that provides enhanced privacy and security protections to a user by enabling the user to maintain custody of his or her login credentials. A syncing agent in coordination with a system add-on coordinates log-in to a remote system and storage of session information. Syncing agent utilizes the session agent to retrieve additional information on behalf of the user or perform other tasks on the remote server.
G06F 16/27 - Replication, distribution or synchronisation of data between databases or within a distributed database systemDistributed database system architectures therefor
A user account evaluation system is disclosed for evaluating risk associated with a user account. The system may obtain user account data associated with many user accounts, select a statistically significant subset of the user accounts, and then process (e.g., to determine types of the user accounts, etc.) and analyze the subset of user accounts to generate a plurality of evaluation models. When a new user account is accessed by the system, user account data may be obtained for the new user account, and the new user account may be evaluated based on the plurality of evaluation models. Accordingly, a plurality of evaluation parameter scores may be generated for the new user account, each of which may indicate an amount of risk associated with the user account. Some embodiments of the present disclosure may include machine learning and/or artificial intelligence methods to improve evaluation of the user accounts.
Systems and methods for data parsing are disclosed. In one aspect, a method of parsing raw data associated with one or more transactions involves receiving a text string including raw data for a transaction, matching the text string to a plurality of locations within a location corpus to extract location information from the text string, and identifying a candidate entity from the text string based on a similarity score with respect to a plurality of entities within an entity corpus. The method further involves in response to the similarity score of the identified candidate entity being less than a threshold score, generating entity information using the tokens indicative of entity information, and generating normalized transaction data including the extracted location information and one of the identified candidate entity or the generated entity information.
A permissions management system is disclosed for enabling a user to securely authorize access to user accounts and/or securely authorize execution of transactions related to user accounts via one or more application programming interfaces (“APIs”) and/or one or more authorization mechanisms.
A system and method that includes receiving a client data packet from network traffic with a client device; extracting a set of packet components from the client data packet; generating a client fingerprint from the set of packet components; assigning a client type to the network traffic using the client fingerprint; and optionally filtering the network traffic of the client device based at least in part on the client type.
H04L 43/026 - Capturing of monitoring data using flow identification
H04L 43/028 - Capturing of monitoring data by filtering
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
H04L 9/06 - Arrangements for secret or secure communicationsNetwork security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
H04L 43/04 - Processing captured monitoring data, e.g. for logfile generation
54.
Secure authorization of access to user accounts by one or more authorization mechanisms
A permissions management system is disclosed for enabling a user to securely authorize access to user accounts and/or securely authorize execution of transactions related to user accounts via one or more application programming interfaces (“APIs”) and/or one or more authorization mechanisms.
Systems and methods for data parsing are disclosed. In one aspect, a method of parsing raw data associated with one or more transactions involves receiving a text string including raw data for a transaction, matching the text string to a plurality of locations within a location corpus to extract location information from the text string, and identifying a candidate entity from the text string based on a similarity score with respect to a plurality of entities within an entity corpus. The method further involves in response to the similarity score of the identified candidate entity being less than a threshold score, generating entity information using the tokens indicative of entity information, and generating normalized transaction data including the extracted location information and one of the identified candidate entity or the generated entity information.
A system and method for cloud management of user interactions on a client device comprising: initiating, in response to an initiation request of a client application, processing of a workflow configuration with an initial session state, wherein the workflow is a data model of a graph of nodes connected with directed edges, where the nodes include a set of node types that includes at least a pane node; iteratively processing the workflow configuration, initially using the initial session state, and thereby generating rendered panes for use in a user interaction flow of a client application, which comprises: following a next edge of the workflow configuration to determine a next workflow node, processing the next workflow node, which comprises, when the next workflow node is a pane node, rendering the pane node into a rendered pane, and sending the rendered panes to the client device.
G06F 3/00 - Input arrangements for transferring data to be processed into a form capable of being handled by the computerOutput arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
A system and method for secure permissioning of access to user accounts, including secure distribution of aggregated user account data can include generating a financial report based on account information associated with one or more user accounts; receiving a financial report request for the financial report of the user account, wherein the financial report request is identified as being received from a third-party system; generating an audit report token associated with the financial report; sharing the audit token with the first third-party system in response to the financial report request; and providing the first third-party system account access to the financial report through the report token, where the audit report token can be shared with a second third-party system and provided by the second third-party system in order to confirm authorization to the report and integrity of the report.
Systems and methods for programmatic access of a financial institution system. A normalized API request provided by an application system specifies user information corresponding to at least one account endpoint of an external financial institution system. Responsive to the request, at least one application proxy instance associated with the normalized API request is used to collect transaction information from a corresponding financial institution system by providing the financial institution system with a proprietary API request that specifies at least account credentials associated with the user information. The transaction information is included in at least one proprietary API response provided by the financial institution system. A normalized API response is generated based on the collected transaction information and provided to the application system. Each application proxy instance is constructed to simulate an application of the corresponding financial institution system on behalf of a user associated with the application proxy instance.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
Systems and methods for secure updating of allocations to user accounts are provided. In one aspect, a system includes one or more computer readable storage mediums having program instructions embodied therewith, and one or more processors configured to cause the system to identify an external institution associated with the future transfers, and initiate, based on the identified external institution, a proxy instance of a software application of the external institution to determine a set of endpoints and a set of the future transfers to the endpoints. The system is further configured to receive a request from a user to change at least one of the set of the endpoints and the set of the further transfers to the endpoints, and use the proxy instance, executing the requested change to at least one of the set of the endpoints or the set of the future transfers to the endpoints.
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
Systems and techniques are disclosed for accessing accounts associated with a user and estimating a value of an attribute associated with the user based upon the retrieved account information. Transaction data associated with an account at an external user account system is received. The transactions are categorized into transaction groups. For each transaction group, a confidence value that the group is associated with the attribute is estimated, based at least in part upon a distribution of transaction amounts for the transactions of the group over a time period associated with the group. An attribute value is estimated for each group, based at least in part upon the transaction amounts of the transaction of the group. In addition a value of the attribute for a future time period may be predicted based upon the transaction groups.
A system and method for verifying account ownership using verified deposits. An ACH verification platform may recognize or detect a verification process involving microdeposits. A verification platform may receive and store user login, initiate the deposits, and monitor the user's account to verify that posting of the deposits was successful. In embodiments, a dedicated web form or portal may be provided for receiving verification information.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment
G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
A system and method for assessing digital interactions with a digital third party accounts can include receiving user account credentials for authentication with an external computing system, storing the user account credentials in association with a authentication token and communicating the authentication token to a computing device of an external application service; receiving, through a programmatic communication interface, a request that references the authentication token and digital interaction details; programmatically authenticating, using the stored user account credentials, as a user account with the external computing system and retrieving account data; processing the account data in combination with the digital interaction details and thereby generating a digital interact assessment; and initiating execution of a digital interaction based in part on the digital interaction assessment.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
65.
System and method for programmatically accessing financial data
Systems and methods for programmatic access of external financial service systems. An application proxy instance is created that simulates an application of an external financial service system. A normalized account request is received for financial data of the external financial service system for a specified account. The normalized account request is provided by an external financial application system by using a financial data API of the financial platform system. Responsive to the normalized account request, communication is negotiated with the external financial service system by using the application proxy instance to access the requested financial data from the external financial service system by using a proprietary Application Programming Interface (API) of the external financial service system. The financial data is provided to the external financial application system as a response to the normalized account request.
Systems and techniques are disclosed for accessing accounts associated with a user and estimating a value of an attribute associated with the user based upon the retrieved account information. Transaction data associated with an account at an external user account system is received. The transactions are categorized into transaction groups. For each transaction group, a confidence value that the group is associated with the attribute is estimated, based at least in part upon a distribution of transaction amounts for the transactions of the group over a time period associated with the group. An attribute value is estimated for each group, based at least in part upon the transaction amounts of the transaction of the group. In addition a value of the attribute for a future time period may be predicted based upon the transaction groups.
A system and method for linking to accounts using credential-less authentication that includes: within a first application context at an account-linking computing service: receiving a request to establish an account link, establishing the account link to a user account of an account service using user credentials, and receiving user identifying information of the first application context and storing the user identifying information in association with the account link; and within a second application context at the account-linking computing service: receiving user identifying information of the second application context, searching and identifying a candidate account link using the user identifying information of the second application context, verifying eligibility for access to the account link, and permitting access to the account link upon successful verification of eligibility.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
A user account evaluation system is disclosed for evaluating risk associated with a user account. The system may obtain user account data associated with many user accounts, select a statistically significant subset of the user accounts, and then process (e.g., to determine types of the user accounts, etc.) and analyze the subset of user accounts to generate a plurality of evaluation models. When a new user account is accessed by the system, user account data may be obtained for the new user account, and the new user account may be evaluated based on the plurality of evaluation models. Accordingly, a plurality of evaluation parameter scores may be generated for the new user account, each of which may indicate an amount of risk associated with the user account. Some embodiments of the present disclosure may include machine learning and/or artificial intelligence methods to improve evaluation of the user accounts.
A system and method that includes receiving a client data packet from network traffic with a client device; extracting a set of packet components from the client data packet; generating a client fingerprint from the set of packet components; assigning a client type to the network traffic using the client fingerprint; and optionally filtering the network traffic of the client device based at least in part on the client type.
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
H04L 43/026 - Capturing of monitoring data using flow identification
H04L 29/06 - Communication control; Communication processing characterised by a protocol
H04L 43/028 - Capturing of monitoring data by filtering
H04L 9/06 - Arrangements for secret or secure communicationsNetwork security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
H04L 43/04 - Processing captured monitoring data, e.g. for logfile generation
A system and method for aggregating account data, and more specifically, a system and method for aggregation of financial account data that provides enhanced privacy and security protections to a user by enabling the user to maintain custody of his or her login credentials. A syncing agent in coordination with a system add-on coordinates log-in to a remote system and storage of session information. Syncing agent utilizes the session agent to retrieve additional information on behalf of the user or perform other tasks on the remote server.
G06F 16/27 - Replication, distribution or synchronisation of data between databases or within a distributed database systemDistributed database system architectures therefor
G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
Systems and methods for programmatic access of a financial institution system. A normalized API request provided by an application system specifies user information corresponding to at least one account endpoint of an external financial institution system. Responsive to the request, at least one application proxy instance associated with the normalized API request is used to collect transaction information from a corresponding financial institution system by providing the financial institution system with a proprietary API request that specifies at least account credentials associated with the user information. The transaction information is included in at least one proprietary API response provided by the financial institution system. A normalized API response is generated based on the collected transaction information and provided to the application system. Each application proxy instance is constructed to simulate an application of the corresponding financial institution system on behalf of a user associated with the application proxy instance.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
72.
Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
G06Q 40/00 - FinanceInsuranceTax strategiesProcessing of corporate or income taxes
H04L 29/06 - Communication control; Communication processing characterised by a protocol
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
H04L 29/06 - Communication control; Communication processing characterised by a protocol
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
A system and method for secure permissioning of access to user accounts, including secure distribution of aggregated user account data can include generating a financial report based on account information associated with one or more user accounts; receiving a financial report request for the financial report of the user account, wherein the financial report request is identified as being received from a third-party system; generating an audit report token associated with the financial report; sharing the audit token with the first third-party system in response to the financial report request; and providing the first third-party system account access to the financial report through the report token, where the audit report token can be shared with a second third-party system and provided by the second third-party system in order to confirm authorization to the report and integrity of the report.
A system and method for verifying account ownership using verified deposits. An ACH verification platform may recognize or detect a verification process involving microdeposits. A verification platform may receive and store user login, initiate the deposits, and monitor the user's account to verify that posting of the deposits was successful. In embodiments, a dedicated web form or portal may be provided for receiving verification information.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentialsReview and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/10 - Payment architectures specially adapted for electronic funds transfer [EFT] systemsPayment architectures specially adapted for home banking systems
G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
76.
Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
G06Q 40/00 - FinanceInsuranceTax strategiesProcessing of corporate or income taxes
H04L 29/06 - Communication control; Communication processing characterised by a protocol
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
Systems and methods for programmatic access of external financial service systems. An application proxy instance is created that simulates an application of an external financial service system. A normalized account request is received for financial data of the external financial service system for a specified account. The normalized account request is provided by an external financial application system by using a financial data API of the financial platform system. Responsive to the normalized account request, communication is negotiated with the external financial service system by using the application proxy instance to access the requested financial data from the external financial service system by using a proprietary Application Programming Interface (API) of the external financial service system. The financial data is provided to the external financial application system as a response to the normalized account request.
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
H04L 29/06 - Communication control; Communication processing characterised by a protocol
H04L 9/32 - Arrangements for secret or secure communicationsNetwork security protocols including means for verifying the identity or authority of a user of the system
Systems and methods for programmatic access of a financial institution system. A normalized API request provided by an application system specifies user information corresponding to at least one account endpoint of an external financial institution system. Responsive to the request, at least one application proxy instance associated with the normalized API request is used to collect transaction information from a corresponding financial institution system by providing the financial institution system with a proprietary API request that specifies at least account credentials associated with the user information. The transaction information is included in at least one proprietary API response provided by the financial institution system. A normalized API response is generated based on the collected transaction information and provided to the application system. Each application proxy instance is constructed to simulate an application of the corresponding financial institution system on behalf of a user associated with the application proxy instance.
G06Q 20/00 - Payment architectures, schemes or protocols
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
80.
Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
A permissions management system is disclosed for enabling a user to securely authorize a third-party system to access user account data and initiate transactions related to a user account, without disclosing to the third-party system account credentials. The system enables the user to also securely de-authorize the third-party system. For example, records may be automatically generated that securely store account information, including one or more permissions related to the account and/or the third-party. A token associated with a record may be shared with the third-party system, but neither the record itself, nor the user account credentials, may be shared with the third-party. Accordingly, the third-party may request user account data and/or initiate transactions by providing the token, but does not itself know, e.g., the user account credentials. Further, the user may set various permissions related to the token, and may also revoke the token (e.g., de-authorize the third-party), thus providing increased security to the user's account.
Systems and methods for programmatic access of external financial service systems. An application proxy instance is created that simulates an application of an external financial service system. A normalized account request is received for financial data of the external financial service system for a specified account. The normalized account request is provided by an external financial application system by using a financial data API of the financial platform system. Responsive to the normalized account request, communication is negotiated with the external financial service system by using the application proxy instance to access the requested financial data from the external financial service system by using a proprietary Application Programming Interface (API) of the external financial service system. The financial data is provided to the external financial application system as a response to the normalized account request.
patents
