A method of providing sentiment analysis includes aggregating, by a processor, a plurality of text-based comments, classifying, by the processor, the plurality of text-based comments as being associated with a polarity of sentiment, and generating, by the processor, a plurality of phrases from the plurality of text-based comments. The method also includes identifying, by the processor, a predetermined number of most common phrases for a particular polarity of sentiment from the plurality of phrases and outputting, by the processor, a graphic that includes the predetermined number of most common phrases for the particular polarity of sentiment.
Described herein is an identity network for validating the digital identity of a user. The identity network may receive, from a relying party, an identity validation request to validate a digital identity of the user. The identity network may provide, to the relying party, a link associated with an identity provider application based on the identity validation request. The identity network may receive, from an identity provider associated with the identity provider application, a confirmation that the user has successfully accessed the identity provider application via the link. After receiving the confirmation, the identity network may receive from the identity provider, an attribute validation request to validate identity attributes of the user, where the attribute validation request includes a plurality of identity attributes of the user. The identity network may validate the digital identity of the user based on the plurality of identity attributes.
Disclosed herein is an identity network that can provide a universal, digital identity for users that can be used to authenticate the user by an identity provider for relying parties to utilize for confirming the identity of the user during sign-up. The identity network receives a request from a relying party that includes deep linking to an identity provider selected by the user. The request specifies the user and any other information about the user the relying party is requesting. A service of the identity network launches the application for the identity provider on the user's device and the user logs into the identity provider's application, which provides the user authentication/validation and information about the user to the identity network. The identity network can then provide the information to the relying party, which the relying party can rely on for creating an account with the relying party for the user.
A method including sending a registration request comprising a public identifier of a user to a computer-implemented funds transfer network to cause the computer-implemented funds transfer network to send a message to the user using the public identifier of the user to perform a validation that the public identifier is usable to contact the user. The registration request is a request to register an account of the user for real-time payments through the computer-implemented funds transfer network. The method also can include sending a confirmation message to the computer-implemented funds transfer network to validate that the public identifier is usable to contact the user and to cause the computer-implemented funds transfer network to register the user by storing a record in a directory of the computer-implemented funds transfer network that associates the public identifier with a private identifier. The private identifier is associated with the account of the user. The private identifier is not shared with the user. The private identifier stored in the directory of the computer-implemented funds transfer network is usable by the computer-implemented funds transfer network, when a sender initiates a funds transfer request to pay the user using the public identifier of the user, to cause funds to be made available in real-time in the account of the user. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review 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]
G06Q 20/10 - Payment architectures specially adapted for home banking systems
Described herein is an identity network for validating the digital identity of a user based on identity provider validation for relying parties. The identity network may receive a request to validate a user that includes attributes of the user and a device identifier of the device the user is using to access the relying party. The identity network may identify an identity provider for the user based on the device identifier or attributes of the user. The identity network may launch the identity provider application through the relying party application integration of a software development kit. Upon launch, the user may authenticate himself through the identity provider, and the identity provider may provide a second set of attributes of the user to compare with the user provided attributes. The identity network can provide a confidence score to the relying party based on the comparison of the user attribute values.
A synthetic identity detection network may include a communications interface, one or more processors, and a memory having instructions stored thereon. The instructions cause the processors to receive a data inquiry from a requesting system. The data inquiry may include personally identifiable information (PII) data associated with a user. The instructions cause the processors to match the PII data to a plurality of user identities. Each user identity may be associated with at least a portion of the PII data. The instructions cause the processors to identify account statuses associated with accounts associated with the user identities. The instructions cause the processors to generate a code based at least in part on a count of the user identities and the account statuses. The code provides an indication of a likelihood of the user being a synthetic identity. The instructions cause the processors to transmit the code to the requesting system.
A compromised data exchange system extracts data from websites using a crawler, detects portions within the extracted data that resemble personally identifying information (PII) data based on PII data patterns using a risk assessment module, and compares a detected portion to data within a database of disassociated compromised PII data to determine a match using the risk assessment module. A risk score may be assigned to a data item within the database in response to determining the match. In some embodiments, URL data may also be detected in the extracted data. The detected URL data represents further websites that can be automatically crawled by the system to detect further PII data.
In response to a request for risk assessment of a person-to-person (P2P) payment transaction, a risk assessment system returns a payer risk score, a payee risk score and a joint/fusion risk score. Risk scores are based on large amounts of data (including transaction data) provided by multiple financial institutions. The data is sorted and linked to individual people (e.g., common account holders), and assembled by a profile system into payee, payer and joint profiles for purposes of risk evaluation. A database associated with a profile system separately stores the profiles (and associated risk scores). Risk scores (payer, payee and joint) are provided for a transaction in response to a payer ID, a payee ID and transaction data.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A computer-implemented method including receiving a request to facilitate a transfer of funds from a sender account of a sender at a sender financial institution to a recipient account of a recipient at a recipient financial institution. The request can include a public identifier for the recipient but not include an account number of the recipient account at the recipient financial institution. The method also can include determining, using an information directory, a private token for the recipient account based on the public identifier. The method additionally can include transmitting the private token of the recipient account to enable the transfer of the funds from the sender account to the recipient account. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
Disclosed herein is an identity network that can provide a universal, digital identity for users that can be used to authenticate the user by an identity provider for relying parties to utilize for confirming the identity of the user during sign-up. The identity network receives a request from a relying party that includes deep linking to an identity provider selected by the user. The request specifies the user and any other information about the user the relying party is requesting. A service of the identity network launches the application for the identity provider on the user's device and the user logs into the identity provider's application, which provides the user authentication/validation and information about the user to the identity network. The identity network can then provide the information to the relying party, which the relying party can rely on for creating an account with the relying party for the user.
A method implemented via execution of computing instructions configured to run at one or more processors and stored at one or more non-transitory computer-readable media. The method can include receiving, in real-time and through a computer network, a donation authorization from a donor via a donor user interface executed on a donor device. The donation authorization can include a donor token for the donor and a donee first token for a donee. The method further can include after receiving the donation authorization, facilitating, through the computer network, a sender financial institution to settle a donation amount with a receiver financial institution. A settlement time of when the sender financial institution settles the donation amount with the receiver financial institution can be independent from a posting time of when the receiver financial institution posts the donation amount to a donee account for the donee. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A compromised data exchange system extracts data from websites using a crawler, detects portions within the extracted data that resemble personally identifying information (PII) data based on PII data patterns using a risk assessment module, and compares a detected portion to data within a database of disassociated compromised PII data to determine a match using the risk assessment module. A risk score may be assigned to a data item within the database in response to determining the match. In some embodiments, URL data may also be detected in the extracted data. The detected URL data represents further websites that can be automatically crawled by the system to detect further PII data.
36 - Financial, insurance and real estate services
Goods & Services
Financial transaction services, namely, providing secure financial transfer options and transactions; financial transaction processing services provided via an electronic wallet
A method, performable by a data broker, of securely transferring data without passwords may include registering an entity using a FIDO authentication process. The method may include associating, based on a receipt of first access token generated by a data provider using a first OIDC authorization process, the data provider with the entity. The method may include generating a second access token, using a second OIDC authorization process, associated with a data recipient. The method may include receiving a request to transfer requested data from the data provider to the data recipient. The request may include the second access token. The method may include transmitting the first long-lived token to the data provider for receiving the requested data. The method may include transmitting the requested data to the data recipient.
A system includes a processor and a memory accessible to the processor. The memory may store instructions that, when executed by a processor, cause the processor to receive first data associated with a first owner and second data associated with a second owner from a data warehouse. The memory further includes instructions that, when executed, cause the processor to selectively filter the first data according to first data sharing permissions defined by the first owner to produce first filtered data, selectively filter the second data according to second data sharing permissions defined by the second owner to produce second filtered data, and provide an output including the first filtered data and the second filtered data to a data requester.
A method including receiving a request based on a sender initiating a funds transfer, wherein the funds transfer is for the sender to make a payment to a non-financial institution. The sender has a sender account at a sender financial institution. The method also can include obtaining sender identifying information from the sender. The method additionally can include sending at least a recipient public identifier and a payment amount for the payment to the sender financial institution to cause the sender financial institution to send a funds transfer request to a computer-implemented funds transfer network to initiate the payment from the sender account at the sender financial institution to a recipient account at a recipient financial institution. The funds transfer request does not include an account number of the recipient account. The computer-implemented funds transfer network is operated by an entity that is different from the recipient financial institution and the sender financial institution. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review 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]
G06Q 20/10 - Payment architectures specially adapted for home banking systems
A method of transmitting a safety notification comprising: determining a user location of an entity; receiving event data including an event location of an event; determining a range from the event location; and where the user location is within the range, transmitting the safety notification to a user device regarding the event.
A method of determining a fraud network comprising: receiving address information regarding a first address; determining, using an address risk machine learning model, a first address risk score associated with the first address; identifying a first entity associated with the first address based on the first address risk score; determining at least one of a second address and a second entity associated with the first entity; and generating a fraud network profile including the first address, and the at least one of the second address and second entity.
H04L 41/16 - Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
A method of fraud risk assessment, comprising: receiving labeled data that includes address information for one or more addresses and labels corresponding to the one or more addresses; training an address risk machine learning model capable of predicting a risk of fraud for an address by determining relationships among the labeled data; and determining, using the address risk machine learning model, an address risk score of a first address of the one or more addresses based on the labeled data of the first address.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/10 - Payment architectures specially adapted for home banking systems
A method of transmitting a stale notification using one or more processors, comprising: receiving data about an interaction involving a user device, the data including a predefined period of time based on a complexity of the interaction; detecting no user inputs for the predefined period of time; and transmitting a notification to the user device indicating that the interaction is stale.
36 - Financial, insurance and real estate services
Goods & Services
(1) Financial transaction services, namely, providing secure payment and transfer options and transactions; payment processing services provided via an electronic wallet.
A method for sharing digital identity data, the method comprising, using an identity network, receiving a sign-up request for a user from a relying party, providing, for display to a user interface of a user device, a list of identity providers, in response to receiving a selection of the identity provider from the list of identity providers, causing the user interface to display a login page associated with the selected identity provider, receiving, from the selected identity provider, a plurality of identity attributes associated with the user, providing, for display to the user interface, the plurality of identity attributes associated with the user, receiving consent from the user to share the plurality of identity attributes associated with the user with the relying party, and redirecting the user interface to a page associated with the relying party.
A method for sharing digital identity data, the method comprising, using the identity network, receiving an indication of consent from a user device to share a plurality of identity attributes with a relying party, wherein the plurality of identity attributes are associated with a user of the user device, generating an internal authorization code after receiving the consent, providing the internal authorization code to the user device, receiving the internal authorization code from the relying party, in response to receiving the internal authorization code, providing an internal access token to the relying party, receiving the internal access token from the relying party, and in response to receiving the access token, providing the plurality of identity attributes to the relying party.
Disclosed herein is an identity network that provides a universal, digital identity for users to be authenticated by an identity provider for relying parties upon sign-in to the relying party. The identity network receives the sign-in request from a relying party for a user using a user device. The identity network can provide a session identifier to the relying party for the request and launch an identity provider application associated with the user via a software development kit in the relying party application. The user may sign-in to the identity provider via the software development kit, thereby authenticating the user for the relying party. Additionally, the identity provider may generate a risk validation score and provide it to the relying party that provides a confidence value that the user is validly using the user device and a risk score based on device activity on the identity network.
A method of generating an input for a machine learning algorithm may include collecting data records. Each data record may include a plurality of categories of data. The method may include using vector quantization to partition the plurality of data records into a plurality of groupings. Each of the groupings may be based on one or more of the plurality of categories of data. The method may include generating a correlation score for each of the plurality of groupings. The correlation score may be indicative of whether a particular group is indicative of a given outcome.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
G06K 9/62 - Methods or arrangements for recognition using electronic means
35.
IDENTITY PROVIDER SELECTION FOR IDENTITY ATTRIBUTE SHARING PROCESS
Methods of selecting an identity provider using an identity attribute sharing system may include accessing, by a user device, a page of a relying party. The methods may include receiving, by the user device, a selection to utilize an identity network to share a number of identity attributes with the relying party. The methods may include displaying, by the user device, a plurality of identity providers enrolled for use with the identity attribute sharing system. The methods may include receiving, by the user device, a selection of one of the plurality of identity providers. The methods may include providing access to a page of a selected identity provider.
A method of analyzing the effectiveness of a machine learning model may include executing a test procedure of a machine learning model comprising a plurality of input features. The machine learning model may include a lag feature associated with one of the plurality of input features. Executing the test procedure may include querying one or more data sources for historical data records associated with the input features. The lag feature may restrict a query for historical data records from at least one of the data sources to a predetermined time prior to a time of the test procedure of the machine learning model. Executing the test procedure may include receiving the historical data records from the one or more data sources at the machine learning model. Executing the test procedure may include generating an output of the machine learning model.
Methods of selecting an identity provider using an identity attribute sharing system may include accessing, by a user device, a page of a relying party. The methods may include receiving, by the user device, a selection to utilize an identity network to share a number of identity attributes with the relying party. The methods may include displaying, by the user device, a plurality of identity providers enrolled for use with the identity attribute sharing system. The methods may include receiving, by the user device, a selection of one of the plurality of identity providers. The methods may include providing access to a page of a selected identity provider.
A method of operating a machine learning target factory may include generating a plurality of machine learning targets. The method may include storing each of the plurality of machine learning targets on a network-attached database. The method may include receiving, at the network-attached database, a request for at least one of the plurality of machine learning targets for a machine learning model. The method may include providing the at least one of the plurality of machine learning targets to a computing device housing the machine learning model.
Disclosed herein is an identity network that provides a universal, digital identity for users to be authenticated by an identity provider for relying parties upon sign-in to the relying party. The identity network receives the sign-in request from a relying party for a user using a user device. The identity network can provide a session identifier to the relying party for the request and launch an identity provider application associated with the user via a software development kit in the relying party application. The user may sign-in to the identity provider via the software development kit, thereby authenticating the user for the relying party. Additionally, the identity provider may generate a risk validation score and provide it to the relying party that provides a confidence value that the user is validly using the user device and a risk score based on device activity on the identity network.
Methods of selecting an identity provider using an identity attribute sharing system may include accessing, by a user device, a page of a relying party. The methods may include receiving, by the user device, a selection to utilize an identity network to share a number of identity attributes with the relying party. The methods may include displaying, by the user device, a plurality of identity providers enrolled for use with the identity attribute sharing system. The methods may include receiving, by the user device, a selection of one of the plurality of identity providers. The methods may include providing access to a page of a selected identity provider.
A method including receiving, at a payment-messaging system from a biller financial institution, a request comprising a public consumer token of a consumer. The consumer provided the public consumer token to a biller system of a biller for a bill payment by the consumer to the biller. The biller system provided the public consumer token to the biller financial institution. The biller financial institution maintains a biller account of the biller. The acts also can include determining a risk metric representing a risk of using the public consumer token for the bill payment. The acts additionally can include sending the risk metric from the payment-messaging system to the biller financial institution. The biller financial institution sends the risk metric to the biller system to allow the biller to determine whether to assume liability for the bill payment. The acts further can include receiving, at the payment-messaging system from the biller financial institution, an authorization message for the bill payment. The authorization message was provided to the biller financial institution by the biller system. The acts additionally can include sending the authorization message for the bill payment to a consumer financial institution, to cause the consumer financial institution to send a real-time payment message through the payment-messaging system to the biller financial institution to make funds available in real-time in the biller account for the bill payment. Other embodiments are described.
G06Q 20/10 - Payment 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]
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A method of generating a credit/lending balance sheet may include receiving, from a financial institution, an identifier associated with a request for funds. The method may include identifying one or more financial accounts associated with a debtor who initiated the request for funds based on the identifier. The method may include accessing account data from the one or more financial accounts associated with the debtor. The method may include aggregating the account data from the one or more financial accounts. The method may include generating a balance sheet from the aggregated account data, the balance sheet providing data associated with income and expenses of the debtor.
Disclosed herein is an identity network that can provide a universal, digital identity for users that can be used to authenticate the user by an identity provider for relying parties. The identity network receives a request from a relying party that includes deep linking to an identity provider selected by the user. The request specifies the user as well as any other information about the user the relying party is requesting. A service of the identity network launches the application for the identity provider on the user's device using a software development kit. The user can log into the identity provider's application, which validates the user and provides the user authentication/validation and information about the user to the identity network. The identity network can then provide the indication of the user's authentication and the user information to the relying party.
Disclosed herein is an identity network that can provide a universal, digital identity for users that can be used to authenticate the user by an identity provider for relying parties. The identity network receives a request from a relying party that includes deep linking to an identity provider selected by the user. The request specifies the user as well as any other information about the user the relying party is requesting. A service of the identity network launches the application for the identity provider on the user's device using a software development kit. The user can log into the identity provider's application, which validates the user and provides the user authentication/validation and information about the user to the identity network. The identity network can then provide the indication of the user's authentication and the user information to the relying party.
A payment and authentication network may include a communications interface, one or more processors, and a memory. The memory may have instructions stored thereon that, when executed by the one or more processors cause the one or more processors to receive, using the communications interface, transaction information associated with a transaction from a merchant system and generate a fraud risk score based on the transaction information. The instructions may cause the one or more processors to determine that the fraud risk score is indicative that the transaction is likely fraudulent and transmit an alert to a user device that informs a user of the user device that the transaction is likely fraudulent prior to generating an approval decision for the transaction.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
Systems and methods are provided for implementing reciprocal data sharing in a data exchange system. Limitations may be placed on the amount of data an exchange member may access based on the amount of data contributed. The system may include determining a data contribution associated with a first member of the data exchange, determining a data access limit for the first member based on the data contribution, and providing data to the first member when the first member has not exceeded the data access limit. In some embodiments, there may be separate data access limits for each member of the data exchange, so that a first member may have different access limits when accessing data from a second member, data from a third member, and data from a fourth member. Further, the system may limit a requester to a type of data that corresponds to the type of data contributed.
H04L 67/60 - Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
H04L 47/25 - Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
Described herein is an identity network for authenticating a user for a relying party and providing access to the user's credit report. The identity network may receive an unlock request for the digital identity and credit report of a user from a relying party. In response, the identity network may provide an identity provider link for accessing the identity provider application. The user may login to the identity provider application and provide consent for obtaining the user's credit report. The identity provider provides the identity network with verification of the digital identity of the user and the consent response from the user. The identity network can request access from a credit reporting agency and receive a credit report key in response. The identity network can provide the credit report key to the relying party, which can use the key to access the user's credit report from the credit reporting agency.
Systems and methods including one or more processors and one or more non-transitory storage devices storing computing instructions configured to run on the one or more processors and perform receiving, from a payee system for a payee, a request for a transfer from a payor to the payee, wherein: the payor is associated with a payor user profile of the payee system; and the request comprises a transfer token associated with the payor and the payee; retrieving transfer data based on the transfer token, wherein: the transfer data is associated with the transfer token, a payor financial institution for the payor, and a selected payor account owned by the payor and maintained by the payor financial institution; and the transfer data comprises an access token for the payor financial institution and the payor; using the access token to access one or more eligible payor accounts owned by the payor and maintained by the payor financial institution, the one or more eligible payor accounts comprising the selected payor account; determining a fraud risk score for the transfer; transmitting, to a payee financial institution for the payee, the fraud risk score, wherein: the payee financial institution is configured to determine a transfer decision for the transfer based at least in part on the fraud risk score and information about a payee account for the transfer; and the payee account is owned by the payee and maintained by the payee financial institution; and when the transfer decision comprises an approval of the transfer by the payee financial institution, facilitating the transfer from the selected payor account to the payee account. Other embodiments are disclosed herein.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/10 - Payment architectures specially adapted for home banking systems
G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
55.
SYSTEMS AND METHODS FOR SECURE ELECTRONIC TRANSFERS
Systems and methods including one or more processors and one or more non-transitory storage devices storing computing instructions configured to run on the one or more processors and perform receiving, from a payee system for a payee, a request for a transfer from a payor to the payee, wherein the payor is associated with a payor user profile of the payee system; causing a payor device for the payor to display an authorization user interface for the payor to authorize a payor financial institution to grant an access code to the system; requesting, from the payor financial institution, one or more eligible payor accounts owned by the payor and maintained by the payor financial institution; causing the payor device to display the one or more eligible payor accounts for the payor to determine a selected payor account of the one or more eligible payor accounts for the transfer; determining a fraud risk score for the transfer; transmitting, to a payee financial institution for the payee, the fraud risk score, wherein: the payee financial institution is configured to determine a transfer decision for the transfer based at least in part on the fraud risk score and information about a payee account for the transfer; and the payee account is owned by the payee and maintained by the payee financial institution; when the transfer decision comprises an approval of the transfer by the payee financial institution, facilitating the transfer from the selected payor account to the payee account; generating a transfer token associated with the payor and the payee; storing transfer data for the transfer, the transfer data being associated with the transfer token; and transmitting the transfer token to the payee system, wherein the payee system stores the transfer token with the payor user profile. Other embodiments are disclosed herein.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/10 - Payment 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]
Systems and methods including one or more processors and one or more non-transitory storage devices storing computing instructions configured to run on the one or more processors and perform receiving a request for a transfer from a selected payor account of a payor to a payee; determining a fraud risk score for the transfer; transmitting, to a payee financial institution for the payee, the fraud risk score, wherein the payee financial institution is configured to determine a transfer decision for the transfer based at least in part on the fraud risk score and information about a payee account for the transfer, wherein the payee account is owned by the payee and maintained by the payee financial institution; and when the transfer decision comprises an approval of the transfer by the payee financial institution, facilitating the transfer from the selected payor account to the payee account, wherein facilitating the transfer comprises: sending transfer information to a payor financial institution to cause the payor financial institution to send a request for payment through a real-time settlement network to the payee financial institution to authorize a real-time credit transfer from the selected payor account to the payee account, wherein the real-time credit transfer is settled in real-time through the real-time settlement network. Other embodiments are disclosed herein.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
Systems and methods including one or more processors and one or more non-transitory storage devices storing computing instructions configured to run on the one or more processors and perform receiving, at a system from a payee system for a payee, a request for a transfer from a payor to the payee, wherein: the request is sent by the payee without the payor selecting to use the system for the transfer; the payor is associated with a payor user profile of the payee system; and the request comprises a transfer token associated with the payor and the payee; retrieving a transfer data based on the transfer token, wherein: the transfer data is associated with the transfer token, a payor financial institution for the payor, and a selected payor account owned by the payor and maintained by the payor financial institution; and the transfer data comprises an access token for the payor financial institution and the payor; determining a fraud risk score for the transfer; transmitting, to a payee financial institution for the payee, the fraud risk score, wherein the payee financial institution is configured to determine a transfer decision for the transfer based at least in part on the fraud risk score and information about a payee account for the transfer, wherein: the payee account is owned by the payee and maintained by the payee financial institution; and when the transfer decision comprises an approval of the transfer by the payee financial institution, facilitating the transfer from the selected payor account to the payee account. Other embodiments are disclosed herein.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
Systems and methods including one or more processors and one or more non-transitory storage devices storing computing instructions configured to run on the one or more processors and perform receiving, from a payee system for a payee, a request for a transfer from a payor to the payee; causing a payor device of the payor to display an authorization user interface for the payor to authorize a payor financial institution to grant an access code to the one or more processors; in response to the payor financial institution granting the access code, requesting, from the payor financial institution, one or more eligible payor accounts owned by the payor and maintained by the payor financial institution; causing the payor device to display the one or more eligible payor accounts for the payor to determine a selected payor account of the one or more eligible payor accounts for the transfer; determining a fraud risk score for the transfer; transmitting, to a payee financial institution for the payee, the fraud risk score, wherein: the payee financial institution is configured to determine a transfer decision for the transfer based at least in part on the fraud risk score and information about a payee account for the transfer; and the payee account is owned by the payee and maintained by the payee financial institution; and when the transfer decision comprises an approval of the transfer by the payee financial institution, facilitating the transfer from the selected payor account to the payee account. Other embodiments are disclosed herein.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A system may include an interface configured to couple to a network, and includes a processor and a memory accessible to the processor. The memory may be configured to store instructions that, when executed, cause the processor to process search results corresponding to multiple data owners to selectively filter personally identifiable information (PII) associated with one or more consumers from the set of search results according to data sharing permissions for each of the data owners to produce filtered results. The instructions may further cause the processor to provide the filtered results to a user device through the network.
G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
60.
SECURE ELECTRONIC BILLING WITH REAL-TIME PAYMENT SETTLEMENT
A method including receiving, at a payment-messaging system from a payee financial institution, a request for payor profile information. The request can include a public identifier of a payor. The acts also can include determining, using a directory at the payment-messaging system, the payor profile information based on the request. The payor profile information can include a routing transit number for a payor financial institution that maintains a payor account of the payor when the payor financial institution is enabled to send real-time payments through a real-time settlement network. The payor profile information does not include an account number of the payor account. The acts additionally can include sending, from the payment-messaging system to the payee financial institution, the payor profile information, to cause: the payee financial institution to determine whether the payor profile information includes the routing transit number for the payor financial institution; and the payee financial institution, when the payor profile information includes the routing transit number for the payor financial institution, to send a request for payment through the real-time settlement network to the payor financial institution to allow the payor to authorize a real-time credit transfer from the payor account to a payee account of a payee maintained at the payee financial institution. The real-time credit transfer can be settled through the real-time settlement network. Other embodiments are disclosed.
Disclosed herein is an identity network that provides a universal, digital identity for users to be authenticated by an identity provider for relying parties upon sign-in to the relying party. The identity network receives the sign-in request from a relying party for a user using a user device. The identity network can provide a session identifier to the relying party for the request and launch an identity provider application associated with the user via a software development kit in the relying party application. The user may sign-in to the identity provider via the software development kit, thereby authenticating the user for the relying party. Additionally, the identity provider may generate a risk validation score and provide it to the relying party that provides a confidence value that the user is validly using the user device and a risk score based on device activity on the identity network.
A method including receiving a request based on a sender initiating a funds transfer. The funds transfer is for the sender to make a payment to a non-financial institution. The sender has a sender account at a sender financial institution. The method also can include obtaining sender identifying information from the sender. The method additionally can include sending at least (a) the sender identifying information, (b) a recipient public identifier, and (c) a payment amount for the payment to the sender financial institution to cause the sender financial institution to (i) determine a funds availability of the sender account to initiate the funds transfer for the payment amount and (ii) send a funds transfer request to a computer-implemented funds transfer network to initiate the payment from the sender account at the sender financial institution to a recipient account at a recipient financial institution. The funds transfer request can include the recipient public identifier and the payment amount. The funds transfer request does not include an account number of the recipient account. The computer-implemented funds transfer network can include a first directory mapping the recipient public identifier to a recipient private identifier. The recipient private identifier is embedded with information that identifies the recipient financial institution. The recipient private identifier is not shared with the sender. The computer-implemented funds transfer network is configured to send the recipient private identifier to the recipient financial institution to enable the recipient financial institution to map the recipient private identifier to the account number of the recipient account and make funds available to the recipient account in real-time for the payment. The computer-implemented funds transfer network is operated by an entity that is different from the recipient financial institution and the sender financial institution. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
G06Q 20/10 - Payment 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 including one or more processors, a merchant account database including a plurality of merchant identifiers being associated with a plurality of merchants, a transaction database, and one or more non-transitory computer-readable media storing computing instructions that, when executed by the one or more processors, cause the one or more processors to perform certain acts. The acts can include receiving, at the system and from a mobile device being used by a consumer, a request including a merchant identifier of the plurality of merchant identifiers; determining, at the system and using the merchant account database, first information including a second account identifier for a second account of the merchant at the second financial institution; sending the first information from the system to the first financial institution; receiving in real time over a network, at the system and from the first financial institution, payment information regarding a payment to the second account from a first account of the consumer at the first financial institution to pay the merchant the payment amount for the one or more items; logging the payment information in the transaction database; and sending in real time over the network, from the system to the merchant, a notification of the payment from the consumer to the merchant. Other embodiments are described.
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/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
A method including receiving a funds transfer request initiated by a sender to facilitate a transfer of funds to a recipient. The funds can be transferred from a sender account of the sender at a sender financial institution to a recipient account of the recipient at a recipient financial institution. The funds transfer request can include a public token for the recipient but not including an account number of the recipient account at the recipient financial institution. The public token for the recipient can be confirmed as useable to contact the recipient based on one or more responses by the recipient to one or more authentication request messages provided to the recipient using the public token. The method also can include determining a private token for the recipient account using an information directory based on the public token. The private token can be embedded with information that identifies the recipient financial institution. The method additionally can include providing the private token of the recipient account to the sender financial institution to enable the sender financial institution to initiate the transfer of the funds from the sender account to the recipient account. The account number of the recipient account is not shared with the sender by the sender financial institution or the recipient financial institution. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
65.
Display screen portion with graphical user interface
Disclosed herein is an identity network that can provide a universal, digital identity for users that can be used to authenticate the user by an identity provider for relying parties. The identity network receives a request from a relying party that includes deep linking to an identity provider selected by the user. The request specifies the user as well as any other information about the user the relying party is requesting. A service of the identity network launches the application for the identity provider on the user's device using a software development kit. The user can log into the identity provider's application, which validates the user and provides the user authentication/validation and information about the user to the identity network. The identity network can then provide the indication of the user's authentication and the user information to the relying party.
H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
A method including a system receiving, through a computer network, a donation authorization from a donor via a donor user interface executed on a donor device. The method further can include, after receiving the donation authorization, determining by the system, in real-time, whether the donation authorization complies with a matching policy of the matching donor. The method further can include, after determining that the donation authorization complies with the matching policy, determining by the system, in real-time, a matching donation amount based at least in part on the matching policy. The matching donation amount can be less than, equal to, or greater than the donation amount. The method further can include, after determining the matching donation amount, facilitating by the system, through the computer network: (i) a first electronic fund transfer of the donation amount from the sender account maintained by the sender financial institution to the receiver account maintained by the receiver financial institution; and (ii) a second electronic fund transfer of the matching donation amount from the matching sender account maintained by the matching sender financial institution to the receiver account maintained by the receiver financial institution. Other embodiments are disclosed.
G06Q 30/02 - Marketing; Price estimation or determination; Fundraising
G06Q 20/42 - Confirmation, e.g. check or permission by the legal debtor of payment
G06Q 40/02 - Banking, e.g. interest calculation or account maintenance
G06Q 20/10 - Payment architectures specially adapted for home banking systems
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review 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]
A method including a system receiving, in real-time and through a computer network, a donation authorization from a donor via a donor user interface executed on a donor device of the donor. The donation authorization can comprise: a donation amount, a donor token for the donor, a donee first token for a donee, and/or donee information. The donor token can be uniquely associated with a donor account for the donor, and the donor account can be maintained by a sender financial institution. The donee first token can be uniquely associated with a donee account for the donee, and the donee account can be maintained by a receiver financial institution. The method further can include the system, after receiving the donation authorization, instructing or facilitating, in real-time and through the computer network, the receiver financial institution to post in real-time the donation amount to the donee account. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
Described herein is an identity network for authenticating a user for a relying party and providing access to the user's credit report. The identity network may receive an unlock request for the digital identity and credit report of a user from a relying party. In response, the identity network may provide an identity provider link for accessing the identity provider application. The user may login to the identity provider application and provide consent for obtaining the user's credit report. The identity provider provides the identity network with verification of the digital identity of the user and the consent response from the user. The identity network can request access from a credit reporting agency and receive a credit report key in response. The identity network can provide the credit report key to the relying party, which can use the key to access the user's credit report from the credit reporting agency.
A method including receiving a request based on a sender initiating a funds transfer. The funds transfer can be for the sender to make a payment to a non-financial institution. The sender can have a sender account at a sender financial institution. The non-financial institution can have a recipient account at a recipient financial institution. The method also can include facilitating obtaining sender identifying information from the sender. The method additionally can include facilitating sending at least (a) the sender identifying information, (b) a recipient public identifier of the non-financial institution, and (c) a payment amount for the payment to the sender financial institution to cause the sender financial institution to (i) determine a funds availability of the sender account to make the funds transfer for the payment amount and (ii) send a funds transfer request to a computer-implemented funds transfer network to make the payment from the sender account at the sender financial institution to the recipient account at the recipient financial institution. The funds transfer request can include the recipient public identifier and the payment amount. The funds transfer request does not include an account number of the recipient account. The computer-implemented funds transfer network can include a first directory mapping the recipient public identifier to a recipient private identifier. The computer-implemented funds transfer network can be configured to send the recipient private identifier to the recipient financial institution to enable the recipient financial institution to map the recipient private identifier to the account number of the recipient account and make funds available to the recipient account in real-time for the payment. The computer-implemented funds transfer network can be operated by an entity that is different from the recipient financial institution and the sender financial institution. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review 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 are disclosed in assessing and determining the health of social tokens associated with certain events. More specifically, but not by way of limitation, this disclosure relates to determining dynamic scores associated with social tokens for senders and receivers in those events and using those scores to assess whether to allow or reject the event. An example embodiment may include receiving data associated with a sender including a social token associated with the sender, receiving account data associated with a plurality of accounts maintained at the entities, generating a health score for the social token associated with the sender, receiving data associated with an event initiated by the sender using the P2P account associated with the sender, generating a health score for the social token associated with the receiver, determining a health score for the event, determining that the event should be approved or declined based on the health score for the event, and if declined locking the application at the network device associated with the sender.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
72.
SYSTEM AND METHOD FOR SIMPLIFYING FRAUD DETECTION IN REAL-TIME PAYMENT TRANSACTIONS FROM TRUSTED ACCOUNTS
A system including one or more processors and one or more non-transitory computer-readable media storing computing instructions configured to run on the one or more processors and perform various acts. The acts can include: (a) receiving a payment authorization, through a network, from a sender financial institution; (b) obtaining, in real-time after receiving the payment authorization, a sender status based on sender information of the payment authorization; (c) when the sender status is preauthorized, instructing, through the network and in real-time after obtaining the sender status, a recipient financial institution to bypass a transaction fraud detection mechanism; and (d) instructing, through the network, the recipient financial institution to post a payment amount of the payment authorization to a recipient account in real-time. Other embodiments are described.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
G06N 7/02 - Computing arrangements based on specific mathematical models using fuzzy logic
G06K 9/62 - Methods or arrangements for recognition using electronic means
A method of providing sentiment analysis includes aggregating, by a processor, a plurality of text-based comments, classifying, by the processor, the plurality of text-based comments as being associated with a polarity of sentiment, and generating, by the processor, a plurality of phrases from the plurality of text-based comments. The method also includes identifying, by the processor, a predetermined number of most common phrases for a particular polarity of sentiment from the plurality of phrases and outputting, by the processor, a graphic that includes the predetermined number of most common phrases for the particular polarity of sentiment.
A method of providing sentiment analysis includes training a computer system to identify a polarity of a sentiment for a plurality of phrases and receiving, at the computer system, an input from a website. The input includes a text string including a phrase. The method includes determining, by the computer system, the polarity of the sentiment of the phrase by comparing the phrase to the plurality of phrases and sending, by the computer system, a command to the website that causes the website to display predetermined content based on the determined polarity of the sentiment of the phrase.
A system including one or more processors and one or more non-transitory computer-readable media storing computing instructions configured to run on the one or more processors and perform various acts. The acts can include receiving, in real-time and through a computer network, a payment authorization from a first financial institution. The payment authorization can comprise a payment amount, a recipient account indicator, and a fund withholding instruction for the payment amount and associated with a release condition for the payment amount. The acts also can include after receiving the payment authorization, instructing, through the computer network, a fund withholding financial institution to post the payment amount to a fund withholding account maintained by the fund withholding financial institution. The acts further can include receiving, through the computer network and from the fist financial institution, a release decision that is based on the release condition. When the release decision is to release the payment amount to the recipient, the acts also can include (a) instructing, through the computer network, the fund withholding financial institution to debit in real-time the payment amount from the fund withholding account after receiving the release decision, and (b) instructing, through the computer network, the second financial institution to post in real-time the payment amount to the recipient account after the payment amount is debited from the fund withholding account. Other embodiments are provided.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
09 - Scientific and electric apparatus and instruments
42 - Scientific, technological and industrial services, research and design
Goods & Services
recorded computer software used for identifying participants in communications and transactions conducted over a global computer information and data storage network for the purpose of assuring the true identity of such participants; downloadable computer software used for identifying participants in communications and transactions conducted over a global computer information and data storage network for the purpose of assuring the true identity of such participants computer services, namely, providing electronic signature security verification using technologies, namely, single sign-on technology, biometric hardware and software technology, blockchain technology, to verify personal identity of individuals accessing computer network firewalls, servers, and other network devices in the nature of identifying participants in communications and transactions conducted over a global computer information and data storage network for the purpose of assuring the true identity of such participants; online, non-downloadable computer software used for identifying participants in communications and transactions conducted over a global computer information and data storage network for the purpose of assuring the true identity of such participants
A system includes a processor and a memory accessible to the processor. The memory may store instructions that, when executed by a processor, cause the processor to receive first data associated with a first owner and second data associated with a second owner from a data warehouse. The memory further includes instructions that, when executed, cause the processor to selectively filter the first data according to first data sharing permissions defined by the first owner to produce first filtered data, selectively filter the second data according to second data sharing permissions defined by the second owner to produce second filtered data, and provide an output including the first filtered data and the second filtered data to a data requester.
In response to a request for risk assessment of a person-to-person (P2P) payment transaction, a risk assessment system returns a payer risk score, a payee risk score and a joint/fusion risk score. Risk scores are based on large amounts of data (including transaction data) provided by multiple financial institutions. The data is sorted and linked to individual people (e.g., common account holders), and assembled by a profile system into payee, payer and joint profiles for purposes of risk evaluation. A database associated with a profile system separately stores the profiles (and associated risk scores). Risk scores (payer, payee and joint) are provided for a transaction in response to a payer ID, a payee ID and transaction data.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A system includes a processor and a memory accessible to the processor. The memory stores instructions that, when executed by the processor, cause the processor to determine a privacy policy score for one of an application and a website and provide the privacy policy score to a device.
Systems and methods are provided for implementing reciprocal data sharing in a data exchange system. Limitations may be placed on the amount of data an exchange member may access based on the amount of data that exchange member has contributed. The system may include determining a data contribution associated with a first member of the data exchange, determining a data access limit for the first member based on the data contribution, and providing data to the first member when the first member has not exceeded the data access limit. In some embodiments, there may be separate data access limits for each member of the data exchange, so that a first member may have different access limits when accessing data from a second member, data from a third member, and data from a fourth member. Further, the system may limit a requester to a type of data that corresponds to the type of data contributed.
H04L 67/60 - Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
H04L 47/52 - Queue scheduling by attributing bandwidth to queues
A system may include an interface configured to couple to a network, and includes a processor and a memory accessible to the processor. The memory may be configured to store instructions that, when executed, cause the processor to process search results corresponding to multiple data owners to selectively filter personally identifiable information (PII) associated with one or more consumers from the set of search results according to data sharing permissions for each of the data owners to produce filtered results. The instructions may further cause the processor to provide the filtered results to a user device through the network.
G06Q 20/34 - Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
A method being implemented via execution of computing instructions configured to run at one or more processors and stored at one or more non-transitory computer-readable media. The method can include receiving a transaction amount and a preauthorization code from a first entity. The preauthorization code can include a preauthorization amount, an expiration time, and a digital signature. The transaction amount is for a transaction authorized by a user of a mobile device at a point-of-sale terminal of the first entity. The transaction amount is less than or equal to the preauthorization amount. The mobile device received the preauthorization code and stored the preauthorization code in the mobile device while the mobile device was in data communication with a mobile wallet provider. The mobile device provided a transaction code to the point-of-sale terminal while the mobile device was unable to communicate with the mobile wallet provider. The transaction code includes the preauthorization code, a transaction identifier for the transaction, and the transaction amount. The method also can include verifying the preauthorization code using the digital signature of the preauthorization code. The method additionally can include sending an approval for the transaction to the first entity in real-time while the user remains at the point-of-sale terminal of the first entity. Other embodiments are described.
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 credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A method being implemented via execution of computing instructions configured to run at one or more processors and stored at one or more non-transitory computer-readable media. The method can include receiving, at a mobile device from a point-of-sale terminal of a first entity, an identifier of the first entity, a transaction amount for a transaction, and a transaction identifier for the transaction. The method also can include receiving an authorization from a user of the mobile device for the transaction while the user is at the point-of-sale terminal, the mobile device running a mobile application that is associated with a mobile wallet provider. The method additionally can include determining that the mobile device is unable to communicate with the mobile wallet provider. The method further can include generating an encrypted transaction code. The encrypted transaction code can include a preauthorization from the user to pay the first entity for the transaction amount from a first account of the user maintained by a first financial institution. The method additionally can include sending the encrypted transaction code from the mobile device to the point-of-sale terminal to cause the encrypted transaction code to be sent through a proxy communication channel extending from the point-of-sale terminal, through a transaction system, to the mobile wallet provider, to cause the mobile wallet provider to decrypt the encrypted transaction code and verify the preauthorization from the user, to cause the first financial institution to retrieve from the transaction system an account identifier of a second account of the first entity maintained by a second financial institution based on the identifier of the first entity and send to the transaction system payment information regarding a payment to be made to the second account from the first account for the transaction, to cause the payment information to be routed through the transaction system to the second financial institution, and to cause the point-of-sale terminal to receive a notification of the payment for the transaction in real-time while the user remains at the point-of-sale terminal. Other embodiments are described.
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 credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A method being implemented via execution of computing instructions configured to run at one or more processors and stored at one or more non-transitory computer-readable media. The method can include receiving, at a transaction system being situated along a proxy communication channel extending from a point-of-sale terminal of a first entity to a mobile wallet provider, an encrypted transaction code. The encrypted transaction code can be generated and sent to the point-of-sale terminal by a mobile device that runs a mobile application associated with the mobile wallet provider. The mobile device receives from a point-of-sale terminal an identifier of the first entity, a transaction amount of a transaction, and a transaction identifier for the transaction, receives an authorization from a user of the mobile device for the transaction while the user is at the point-of-sale terminal, and determines that the mobile device is unable to communicate with the mobile wallet provider. The encrypted transaction code includes a preauthorization from the user to pay the first entity for the transaction amount from a first account of the user maintained by a first financial institution. The method also can include sending the encrypted transaction code through the proxy communication channel to the mobile wallet provider, to cause the mobile wallet provider to decrypt the encrypted transaction code and verify the preauthorization from the user. The method additionally can include receiving, from the first financial institution, a request comprising the identifier of the first entity. The method further can include determining an account identifier of a second account of the first entity maintained by a second financial institution based on the identifier of the first entity. The method additionally can include sending the account identifier of the second account to the first financial institution. The method further can include receiving, from the first financial institution, payment information regarding a payment to be made to the second account from the first account for the transaction. The method additionally can include sending the payment information to the second financial institution, to cause the point-of-sale terminal to receive a notification in real-time while the user remains at the point-of-sale terminal. Other embodiments are described.
G06Q 20/36 - Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
G06Q 20/32 - Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
G06Q 20/02 - Payment architectures, schemes or protocols involving a neutral third party, e.g. certification authority, notary or trusted third party [TTP]
A method being implemented via execution of computing instructions configured to run at one or more processors and stored at one or more non-transitory computer-readable media. The method can include receiving a preauthorization code at a mobile device while the mobile device is in data communication with a mobile wallet provider. The preauthorization code can include a preauthorization amount, an expiration time, and a digital signature. The method also can include storing the preauthorization code in the mobile device. The method additionally can include receiving, at the mobile device, an authorization from a user of the mobile device for a transaction having a transaction amount while the user is at a point-of-sale terminal of a first entity. The method further can include determining that the mobile device is unable to communicate with the mobile wallet provider. The method additionally can include verifying that the transaction amount is less than or equal to the preauthorization amount. The method further can include, while the mobile device is unable to communicate with the mobile wallet provider, providing a transaction code from the mobile device to the point-of-sale terminal to cause the first entity to send the transaction amount and the preauthorization code to a transaction system, and to cause the transaction system to send an approval for the transaction in real-time while the user remains at the point-of-sale terminal of the first entity. The transaction code can include the preauthorization code, a transaction identifier, and the transaction amount. Other embodiments are described.
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 credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A compromised data exchange system extracts data from websites using a crawler, detects portions within the extracted data that resemble personally identifying information (PII) data based on PII data patterns using a risk assessment module, and compares a detected portion to data within a database of disassociated compromised PII data to determine a match using the risk assessment module. A risk score may be assigned to a data item within the database in response to determining the match. In some embodiments, URL data may also be detected in the extracted data. The detected URL data represents further web sites that can be automatically crawled by the system to detect further PII data.
A method can include receiving, at the system and from a first entity, a first request for invoicing a user. The first request can have been initiated by a user request of the user in a mobile application running on a mobile device. The method also can include sending, from the system and to a billing entity, a second request for invoicing the user based at least in part on the first request, the second request comprising a public identifier of the user. The method additionally can include, after sending the second request, receiving, at the system and from the billing entity, first information regarding an invoice for the user to pay the billing entity. The method further can include sending, from the system and to the first entity, second information for displaying an interactive invoice to the user. The second information can be based at least in part on the first information. The method additionally can include receiving, at the system and from the first entity, an authorization of the user to pay, in real-time, a payment amount for the invoice. The method further can include facilitating a real-time payment transaction of the payment amount, based on the authorization, from a first account of the user at a first financial institution to a second account of the billing entity at a second financial institution. Other embodiments are described.
A method including receiving a funds transfer request from a sender through a computer network to facilitate a transfer of funds to a recipient. The method also can include determining that the recipient is not a registered user of the computer-implemented funds transfer payment network. The method additionally can include automatically transmitting an invitation to the recipient to join the computer-implemented funds transfer payment network. The invitation can be directed to the recipient using the token for the recipient from the funds transfer request by sending the invitation to the recipient using the token. The method further can include receiving a response to the invitation from the recipient. The method additionally can include collecting identifying information that identifies the recipient. The method further can include creating a record for the recipient in a database of registered users contained in the computer-implemented funds transfer payment network. The method additionally can include providing an identifier of the recipient account to the sender financial institution to enable the sender financial institution to initiate the transfer of the funds from the sender account to the recipient account. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check of credit lines or negative lists
A method including receiving, by a computer system over a computer network from a recipient financial institution, (i) a public identifier associated with a recipient and (ii) a private profile identifier that was generated by the recipient financial institution. The method also can include storing, by the computer system, a record including the public identifier and the private profile identifier in an information directory. The method additionally can include receiving, by the computer system over the computer network, a funds transfer request to transfer funds from a sender account of the sender at a sender financial institution to the recipient account at the recipient financial institution. The method further can include determining, by the computer system, the private profile identifier for the recipient based on the public identifier in the funds transfer request and using the record stored in the information directory. The method additionally can include in response to receiving the funds transfer request, providing the private profile identifier, by the computer system over the computer network, to the sender financial institution to facilitate a transfer of the funds from the sender account at the sender financial institution to the recipient financial institution. Other embodiments are disclosed.
G06Q 20/40 - Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review 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]
G06Q 20/10 - Payment architectures specially adapted for home banking systems
