Patent ID: 12254463

Like reference numerals indicate like elements.

DETAILED DESCRIPTION

This disclosure presents biller exchange computing systems and methods. One or more example embodiments, and/or implementation examples of the disclosed biller exchange computing systems are generally illustrated in the figures. The biller exchange computing systems include two or more members (e.g., consortium members), which may include financial institutions and third party payment processors. Financial institutions may perform “on-us” and/or “off-us” payment transactions. The biller exchange computing systems enable the member financial institutions to conduct transactions by interacting directly with each other rather than via intermediaries, thus increasing transaction efficiency. In other embodiments, intermediaries such as third party payment processors may be used, for example, in situations where third party billers are already registered with such intermediaries. Members may provide secure and real-time or instant payment transactions with minimal time delay, which is achieved through specific technical configurations. Furthermore, the biller exchange computing systems allow consumers, billers, financial institutions, and payment processors to fluidly interact with each other to reduce resistance in information flow.

At a high level, the disclosed biller exchange computing systems and methods may include a distributed application programming interface (API) system and one or more synchronized biller directories, collectively referred to as a payments engine. In some embodiments, the distributed API system is coordinated by a biller exchange computing system (e.g., providing central management). The distributed API system may be deployed on the computing systems of various financial institutions, billers, and on the biller exchange computing system. In some embodiments, financial institutions may create a separate operating entity that implements the centralized biller exchange computing system to enable secure payments. The distributed API system may also enable tokenization of access credentials to validate the payee/payer relationships between financial institutions (e.g., originating and receiving financial institutions), electronic bill inquiries, payment transactions, and so on.

Advantageously, the disclosed biller exchange computing systems and methods allow various financial institutions and billers to achieve improved customer experience, reduce costs, and achieve cross-financial institution integration. Customer experience for retail customers and billers is improved through real-time or instant display and exchange of detailed biller and payment data, expedited payment delivery and receipts, an increase in direct electronic payments, accurate payee creation and linkage, and reduced return and misapplied payment items for billers.

The disclosed biller exchange computing systems enable financial institutions to collaborate and reduce costs by streamlining electronic processing of financial transactions. This improves data security, decreases biller processing exceptions and risks, minimizes the number of parties involved in a transaction by reducing the need to use third-party processors, improves operational efficiency through standardization and reusability of components, and minimizes paper check issuance to payees. As such, the disclosed biller exchange computing systems can minimize data-related reasons for issuing paper checks, which include biller account validation rule failure, invalid actual biller accounts, or incorrect customer-entered payee names or addresses.

Furthermore, the biller exchange computing systems and methods disclosed herein allow financial institutions to reduce transaction costs and to achieve cross financial institution integration in payment processing.

For example, in some embodiments, example biller exchange computing systems and methods may use an API arrangement in which each participating entity (financial institutions, billers, and a centralized biller exchange computer system) exposes a set of APIs that are accessible to other participating entities. For example, each entity may offer an enroll customer to biller API, an inquire biller or bill API, a pay biller API, and a deliver invoice API. For example, if a customer has a demand deposit account at bank A and has a mortgage with bank B, then bank B may offer an enroll customer to biller API that enables setting up bank B as a biller of the customer in the bill pay system of bank A. Thereafter, the customer may then go to online bill pay at bank A and perform other operations that are supported by the other afore-mentioned APIs (in this example, provided by bank B), such as inquire about bills, pay bills, or receive invoices, without needing to visit the website of bank B. Similar functionality may be provided with respect to other billers (i.e., billers that are not financial institutions) that provide the aforementioned APIs. Hence, for example, a biller may offer an enroll customer to biller API that enables setting up the biller as a biller of the customer in the bill pay system of bank A. Thereafter, the customer may then go to online bill pay at bank A and perform other operations that are supported by the other afore-mentioned APIs (in this example, provided by the biller), such as inquiring about bills and paying bills. For example, the customer may be able to review historical transactions with the biller from the online banking website of the financial institution, retrieve copies (e.g., portable document format (PDF) copies) of recent statements, pay bills, and so on, all in real time and without needing to visit the website of the biller.

The embodiments of the biller exchange computing systems and methods described herein improve computer-related technology and includes performing, using specifically configured processors, computing devices, and computing systems, steps that cannot be done by conventional computing systems or human actors. For example, the biller exchange computing systems may be configured to execute specific data flow sequences, using one or more processors of an example biller exchange computing system, to process data relevant to payment processing transactions. Such data includes counterparty validation and historical payment transactions. This data may be used to generate programmatically codified counterparty relationships and/or to enable the generation of bills by making predictions based on historical data (e.g., payment amount predictions, due date predictions, etc.).

Advantageously, the embodiments of the biller exchange computing systems and methods described herein allow consortium members (e.g., financial institutions) to minimize fraud through advance counterparty verification and by securely exchanging sensitive customer and payment data, through an API of the biller exchange computing system, in a tokenized form.

As another advantage, the API infrastructure of the present disclosure allows for streamlining financial transactions by providing a reduced set of user interfaces delivered to the users via user computing devices (for example, as part of a mobile application, a web-based interface, etc.) and communicatively coupled to the biller exchange computing system through an API. For instance, in an example embodiment described in reference toFIGS.7-9, the biller exchange computing system allows at least six computing devices (a customer computing device, an ODFI application/web server, an ODFI back-end computing system, the biller exchange computing system, an RDFI computing system, and a biller computing device) to seamlessly, in real-time or instant, complete an end-to-end, secure payment transaction, inclusive of processing a customer payment request, counterparty verification using tokenized information, and a funds transfer, using fewer function calls made by each of the above parties at relevant times using a single distributed API. From the perspective of the consumer, the consumer is provided with the ability to do more at a single online/mobile banking website, which reduces or eliminates the need for the consumer to visit various biller websites, and reduces the need of the various biller websites to authenticate the consumer and serve up web pages detailing the current account status and payment history of the consumer.

Referring now toFIGS.1-2B,FIGS.1-2Bare diagrams of example bill payment infrastructures that use biller exchange computing systems and methods. Each ofFIGS.1-2Bprovide details about different aspects of the bill payment infrastructure. Generally,FIGS.1-2Bdescribe, according to various embodiments, the mechanics by which a financial institution makes a payment to a biller at the request of a bill pay customer. The payment infrastructures shown in these Figures include the biller exchange computing systems and methods disclosed herein. At a high level, the biller exchange computing systems and methods disclosed herein standardize the APIs to enable system interoperability and centralize bill presentment and payment processing capabilities. One of skill will appreciate that various features of the Figures may be combined according to various embodiments.

Referring now toFIG.1,FIG.1is a block diagram of an example bill payment infrastructure including third-party processor entities, where the bill payment infrastructure includes the biller exchange computing systems and methods. The systems ofFIG.1are shown from the perspective of a financial institution making a payment to a biller. The illustrated various systems may provide a data management and communication platform for entities associated with these individual providers to perform transactions. The configuration and arrangement of these systems, and the corresponding methods for procuring, storing, securing, managing, and communicating the data can substantially affect the efficiency and capabilities of transactions, such as payment transactions, among parties associated with these different providers. The features implemented by the financial institution may include a mobile/online banking website102, a bill pay system104, and a biller processing system106.

InFIG.1, a bill pay customer101is shown on the far left, and various types of billers are shown on the far right. The various types of billers include an on-us biller114, off-us banking billers136, and off-us non-banking billers132,134. The biller132is an individual/person payee, to whom the bill pay customer101may also wish to make a payment. Also shown located between the bill pay customer101on the left and the billers114,132,134and136on the right are various payment systems106,108,110, and112which may be used to make payments to the billers114,132,134and136. The payment systems106,108,110, and112provide various types of resources that enable making payments. The resources that each provides are indicated with legends numbered1through5. The resources provided include bill/payee directories (1), payee validation (2), electronic payments (3), electronic bills (4), and paper check payments (5). Different payment systems and different resources may be used to make a given payment, depending on the type of biller, as described in greater detail below.

The bill pay customer101can be an individual or an institution. For example, an individual bill pay customer101may want to use the bill payment infrastructure100to pay a credit card bill, mortgage bill, utility bill, internet bill, etc. The bill pay customer101may use a computing device to interact with an online/mobile banking website102of the financial institution of the bill pay customer101. While in the online/mobile banking website102, the bill pay customer may interact with a bill pay system104of the financial institution. The interaction may include data input, responding to requests and verifications, and obtaining secure information for making transaction decisions. The computing device of the customer101may be configured to connect to a bill pay system104using various communication methods, such as via the internet, a local endpoint, etc.

The bill pay system104may include a directory of biller-payees. For example, if the individual bill pay customer101has an account with a utility company, the utility company may be included in the directory as a payee. To add the utility company as a biller, the customer101may access the biller directory and locate the utility company within the biller directory. Generally, a biller directory is a data store that contains payee information, such as routing information, account information, payee financial institution name and/or identifier, etc. The information in the biller directory may, for example, be provided by the biller itself during a biller registration (enrollment) process. The biller directory provides an easy way for the customer101to set up a new payee in the bill pay system100, and ensures that the correct account information, routing information, etc., will be used for the newly set up biller when the customer101makes payments to the biller.

The bill pay system104is communicatively coupled (e.g., via a network) to several systems, including the internal “on-us” payment processing system106, the third-party processor system108, the P2P payment computer system110(e.g., such as Zelle®), and a third-party check printing system112.

Generally, each of these respective systems is suitable for processing payments under specific scenarios. For example, the internal on-us payment processing system106may be configured to process payments made in the context of an “on us” billing relationship, such as when the same financial institution holds a deposit account and a credit card account (i.e., the “on-us” biller) of the bill pay customer101. The internal on-us biller processing system106may also process “off-us” banking billers136, such as a utility company that uses the same bank as the bill pay customer101.

The third-party processor system108may be configured to process payments made to “off-us” billers, including both banking and non-banking billers. The third-party processor system108may further be configured to process electronic invoices or bills from off-us billers. For example, some billers may have registered with the third party processor system108and not with the financial institution. In such scenarios, the account information, routing information, etc., may be stored in the biller directory of the third party processor system108, and made accessible to the bill pay system104via, for example, an API connection, such that the bill pay system104can make a payment to the biller through the third-party processor system108.

The P2P payment computer system110may be configured to process peer-to-peer payments, such as when the bill pay customer101pays another individual. The third-party check printing system112may process paper checks118for any of the above scenarios. In some embodiments, the biller exchange computing systems disclosed herein uses the third-party printing system112to process, issue, or receive check payments118, for example, via check printer or mail delivery, as a compatibility mechanism to handle paper checks. The P2P payment computer system110may further be coupled with or connected to the biller exchange computing systems and methods disclosed herein, and thus be modified, changed, upgraded, or otherwise improved to process transactions.

Also shown inFIG.1are a biller exchange computing system150(sometimes referred to as an on-we exchange computing system), one or more additional financial institutions152, and additional billers154connected to the one or more additional financial institutions and the biller exchange computing system. These features are described in greater detail below in connection with the Figures that follow.

Referring now toFIG.2A,FIG.2Adescribes at a high level a centralized biller exchange computing system210that enables communication between multiple financial institutions and billers. The infrastructure ofFIG.2Ais shown from the perspective of the biller exchange computing system210, which provides the API features that connects multiple billers and financial institutions. The biller exchange computing system210may perform or enable both on-us and off-us billing transactions, among other various types of transactions. The biller exchange computing system210may be communicatively coupled to various financial institutions204, such as banks or similar entities receiving, lending, collecting, investing, borrowing, or otherwise transferring funds as an agent or a principal in association with one or more separate entities. Each of these financial institutions204can have its own set of “on-us” billing products, such as mortgage loans, credit cards, etc.

As shown, each of these financial institutions204can also have its own relationships with one or more “off-us” billers202, which can be banking or non-banking billers. Through the biller exchange computing system210, customers may have enhanced access to billing information associated with the various billers. These relationships are managed by the biller exchange computing system210through a secure enrollment process (for example, using the OAuth authorization protocol as described further herein). The secure enrollment process may be a one-time process or may include periodic information intake. The secure enrollment process may require multi-factor authorization or other identification/verification process.

According to various implementations, the biller exchange computing system210can utilize a distributed API system, which can include callable functions accessible to the computing systems of the various financial institutions204and/or “off-us” billers202. The distributed API can be deployed on the biller exchange computing system210, on the computing systems of the various financial institutions204, and/or on the computing systems of the various “off-us” billers202.

The biller exchange computing system210enables real-time executions, including for example, customer-biller enrollment, biller information inquiry, payment transactions, and delivery of invoices or bills. In addition, the biller exchange computing system210may provide expedited access to biller data and payment transactions across multiple different financial institutions204. The distributed API is configured to enable bill presentment requests, payment requests, enrollment, data synchronization, and/or clearance and settlement activities.

Referring now toFIG.2B,FIG.2Bdescribes at a high level a bill payment infrastructure that includes one or more biller processors and a biller exchange computing system, such as the biller exchange computing systems ofFIG.1andFIG.2A. The infrastructure ofFIG.2Bis shown from the perspective of a biller processor.

Generally, a biller processor is an intermediary entity between a biller and a biller's financial institution. A biller processor may be a financial institution's biller processor250a, the biller financial institution's wholesale biller processor250b, or a third-party biller processor250c. A financial institution's biller processor250amay be internal to or associated with a financial institution, such as an on-us biller254a. For example, a bank may offer a credit card product, a mortgage product, and various lines of credit and loan products. For these on-us billers (e.g., the bank's own billers or products), the bank may use the financial institution's biller processor250ato route the payments to and from recipient banks, where each product may have different accounts to which the funds are routed such that each product is associated with an individual biller. A biller financial institution's wholesale biller processor250bmay be associated with wholesale biller products254boffered by a financial institution. For example, a bank may have a commercial banking product offered to large retailers, such that the bank is a wholesale biller for the payments processed on behalf of the retailer, where the bank is the custodian of the retailer's account to which the payments are posted. A third-party biller processor250cmay be associated with a third-party biller254c, such that payments may be routed to the third-party biller processor250c. In some embodiments, each of the financial institution's biller processor250a, the biller financial institution's wholesale biller processor250b, or a third-party biller processor250chas its own biller directory, which may be synchronized via the biller processor API252as described further herein.

Each biller processor is associated with a biller processor computing system250(e.g., each biller processor may have its own computing system250). The biller processor computing system250includes a biller processor API250. The biller processor API250is managed and/or deployed using the biller exchange computing system and is structured to connect multiple billers with financial institutions via biller processors, as described further herein. The biller processor API250enables biller processors to participate in payment ecosystems and processes described further herein.

FIGS.3-6show various aspects of biller exchange computing systems and methods, according to example embodiments. Generally, biller exchange computing systems and methods disclosed herein provide a set of standardized APIs (e.g. distributed APIs) and processing capabilities (collectively, also sometimes referred to as a payments engine) that enable financial institutions to make payments to billers at the request of bill pay customers or in response to receiving an invoice from a biller. The payments engine disclosed herein is structured to enable interoperability among various actors in payments ecosystems described above. For example, the payments engine disclosed herein can be used to enable bill presentment requests, payment requests, enrollment, data synchronization, and/or clearance and settlement activities.

System interoperability, enabled by the systems and methods of the present disclosure, provides the technical benefit of efficiency in incorporating new member systems into the exchange via ready-to-deploy APIs and related electronic data interchange (EDI) functionality. This benefit is particularly evident in hybrid environments, where participant systems may each operate according to different specifications but are nevertheless enabled to exchange transaction data in a consistent format via the APIs disclosed herein. A secondary technical benefit of a standardized API is its improved interface and transaction status monitoring.

To enable system interoperability, transactions are implemented through a distributed set of APIs. Some aspects thereof may be structured according to standardized formats such that various parties may send and receive data according to a predetermined protocol (e.g., EDI format and messaging schema.) Further, in some embodiments, as described herein, the systems and methods of the present disclosure may make use of existing EDI specifications but further enhance EDI messages developed according to these specifications to accommodate exchange participant requirements. Enhancing already existing EDI specifications and/or authorization infrastructures, such as OAuth, provides the technical benefit of streamlined participant on-boarding, API deployment, and system integration. At the same time, the ability to further augment already existing specifications and authorization infrastructures ensures that system security is not compromised as a result of standardization. This is achieved, in some embodiments, by supporting institution-specific security requirements through extensible tokenization, as discussed further herein.

FIG.3shows details of network interconnection and logic contained at various computer systems of financial institutions, billers, bill pay customers, and the biller exchange computing system.FIG.4shows details of data flows between financial institutions, billers, and the biller exchange computing system. In some embodiments, the biller exchange computing system is implemented by a consortium of financial institutions, and therefore is sometimes referred to as an “on-we” exchange computing system. In some embodiments, one or more financial institutions may perform one or more of the functions of the biller exchange computing system such that, in some implementations, the biller exchange computing system is not implemented by a stand-alone entity.FIGS.5and6show example data models for the payments engine embodied in the systems ofFIGS.3and4.

Referring now toFIG.3,FIG.3is a block diagram of an example bill payment computing environment using biller exchange computing systems and methods applicable to the example bill payment infrastructures disclosed herein. The bill payment computing environment may include a biller computing device304, a financial institution computing device320, a clearinghouse computing device326, a user computing device354, a biller exchange computing system330, and/or a biller processor computing system350. According to various embodiments, all or some of these components can be standalone or combined. For example, any of the biller computing system304, financial institution computing system320, clearinghouse computing system326, and/or biller processor computing system350can be individual devices or combined/integrated with the biller exchange computing system330. In one example embodiment, the biller exchange computing system330may be structured to manage and deploy aspects of its payments engine via the APIs. The API libraries may be installed on the respective computing systems and/or made accessible to the respective computing system(s) without being installed on the respective computing systems.

In the embodiment ofFIG.3, the biller exchange computing system330is managed and/or operated a consortium of financial institutions, such as banks. The biller computing system304is managed and/or operated by a biller. Generally, the biller holds a deposit account at a financial institution that receives payment transactions where payment funds are deposited into the deposit account of the biller. The biller processor computing system350is managed by a biller processor.

As shown, each of the user computing device354(e.g., used by the bill pay customer), the biller computing system304, the financial institution computing system320, the clearinghouse computing system326, the biller exchange computing system330, and the biller processor computing system350are communicatively coupled via the network314. The network314is a data exchange medium, which may include wireless networks (e.g., cellular networks, Bluetooth®, WiFi, Zigbee®, etc.), wired networks (e.g., Ethernet, DSL, cable, fiber-based, etc.), or a combination thereof. In some embodiments or combinations, the network314includes a local area network or a wide area network. In some embodiments, the network314includes the internet. The network314is enabled by short- and/or long-range communication technologies, such as Bluetooth® transceivers, Bluetooth® beacons, RFID transceivers, NFC transceivers, Wi-Fi transceivers, cellular transceivers, wired network connections (e.g., Ethernet), etc.

Each of the biller computing system304, the financial institution computing system320, the clearinghouse computing system326, the biller exchange computing system330, and the biller processor computing system350have respective network interface circuits, such as the network interface circuits310,324,328,334and354. The network interface circuits310,324,328,334and354may include components described herein and/or additional similar components that allow and/or enable connectivity to the network314. In some embodiments, data that passes through the respective network interface circuits310,324,328,334and354is cryptographically protected (e.g., encrypted) such that each of the network interface circuits310,324,328,334and354is a secure communication module.

In some embodiments, data passing through the respective network interface circuits310,324,328,334and354is tokenized such that sensitive data (for example, account number(s), user location, personally identifiable information, and the like) is obscured for transmission within or outside the computing environment. Various communication protocols can be used, including, for example, any of the Internet protocol (IP), transmission control protocol (TCP), hypertext transfer protocol (http), simple object access protocol (SOAP), file transfer protocol (FTP), etc. In some embodiments, secure versions of internet protocols may be used to exchange data via the network interface circuits310,324,328,334and354, such as IPsec, https://, etc.

Data, messages, packages, etc. may be transferred over the network314, through network interface circuits310,324,328,334and354, using application programming interfaces (APIs)310,322,332,354and356. For example, each entity may offer an enroll customer to biller API, an inquire biller or bill API, a pay biller API, and a deliver invoice API. In some embodiments, some or all functions of the API can be stored in a storage media that is communicatively coupled but not local to the respective system, such as cloud-based storage. Thus, the functions of the API can be executed by or on each respective computing environment.

The distributed API is used by computing systems to exchange data and make function calls in a structured format. The distributed API (e.g., biller APIs308, financial institution APIs322, exchange APIs332, biller processor API352, bill pay user financial institution API356, etc.) may be configured to specify an appropriate communication protocol using a suitable EDI standard or technology. The EDI standard (e.g., messaging standard and/or supporting technology) may include any of a SQL data set, a protocol buffer message stream, an instantiated class implemented in a suitable object-oriented programming language (e.g., Java, Ruby, C#, etc.), an XML file, a text file, an Excel file, a web service message in a suitable web service message format (e.g., representational state transfer (REST), simple object access protocol (SOAP), web service definition language (WSDL), JavaScript object notation (JSON), XML remote procedure call (XML RPC), etc.). As such, EDI messages may be implemented in any of the above or using another suitable technology.

Further, in some embodiments, data is exchanged by components of the payments engine using web services. Where data is exchanged using an API configured to exchange web service messages, some or all components of the computing environment may include or may be associated with (e.g., as a client computing device) one or more web service node(s). The web service may be identifiable using a unique network address, such as an IP address, a uniform resource locator (URL), etc. Some or all components of the computing environment may include circuits structured to access and exchange data using one or more remote procedure call protocols, such as Java remote method invocation (RMI), Windows distributed component object model (DCOM), etc. The web service node(s) may include a web service library comprising callable code functions. The callable code functions may be structured according to a predefined format, which may include a service name (interface name), an operation name (e.g., read, write, initialize a class, etc.), operation input parameters and data type, operation return values and data type, service message format, etc. Examples of callable code functions are provided further herein as embodied in various components of the payments engine, such as an example API for biller enrollment, example API for bill inquiry and presentment, example API for payments, and example API for biller directory synchronization.

According to various embodiments, each of the biller computing system304, financial institution computing system320, clearinghouse computing system326, biller exchange computing system330, and biller processor computing system350may include a processor, a memory, at least one electronic circuit and at least one data storage entity for implementing the methods as disclosed. The processor may be a stand-alone or dedicated processor and/or a shared (virtualized) processing resource. The memory may be a stand-alone or dedicated memory device and/or a shared (virtualized) memory resource. The processing resource and/or memory resource may be dynamically allocated as needed to perform the functionality described herein. As used herein, the terms “processor” and “processing resource” are used interchangeably, as are the terms “memory” and “memory resource”. The circuits may include instructions stored in the memory (whether the memory associated with a particular computing system or with another system, such as the biller exchange computing system) and executed by the processor. The circuits may include various code, functions and resources (e.g., files, compiled objects, reference libraries, etc.) that comprise, in whole or in part, various APIs.

More specifically, one or more electronic circuit(s) of the biller computing system304, financial institution computing system320, clearinghouse computing system326, biller exchange computing system330, or biller processor computing system350may be implemented as software code suitable for compilation, object code, executable file(s) and/or code, a set of machine language instructions, and/or in another suitable form for carrying out the computer-implemented method(s) described herein. In some embodiments, the one or more electronic circuit(s) may be implemented in a distributed fashion such that at least some of the code is executed and/or compiled on a system that is different from the system hosting the code, executable files, etc. These circuits may be structured to interact (exchange data, instructions, electronic signals, etc.) with one another, for example, through the API of the respective system.

According to various embodiments, these electronic circuits may be deployed to client systems (e.g. biller computing system304, financial institution computing system320, etc.) in a “light” fashion such that no installation is required, which provides the technical benefit of streamlined application deployment. For example, functionality provided by the circuits can be made accessible to the bill pay user computing device354, financial institution321, etc. through a web browser, a browser plug-in with navigable controls, an applet, a virtual application hosted externally to the respective computing system and deployed, by the payments engine of the biller exchange computing system330, in a software-as-a-service mode, etc. Alternatively or additionally, the functionality provided by the circuits can be deployed and made accessible as an application including executable code packages and the like, which provides the technical benefit of API extensibility by exchange participants.

One or more data storage entities of the biller computing system304, financial institution computing system320, clearinghouse computing system326, biller exchange computing system330, and the biller processor computing system350may be implemented as an electronic structure(s) suitable for storing information, including, for example, one or more persistent electronic structures, such as one or more database(s), electronic file(s), data mart(s), distributed ledger(s) and the like. The data stored in the one or more data storage entities may be stored in a multidimensional form such that the structure of the data storage entity has two dimensions (e.g., a look-up table having indexed data) or more (e.g., a relational database, a multi-dimensional database, an online analytical processing (OLAP) cube, etc.).

The circuits and/or data storage entities may be combined as needed such that one or more data storage entities and/or circuit(s) are implemented in a hybrid form. An example of a hybrid implementation is a data storage entity having a shell and/or providing an API such that a library of code (for example, executable functions containing Data Manipulation Language (DML) instructions) may be used by entities within or outside the computing environment. For example, the exchange data vault340and/or biller directory341of the payments engine of the biller exchange computing system330may be coupled to a code library (e.g., API functions that call stored procedures implemented by a DBMS engine that underlies the vault or directory, etc.), which may be structured to support various system interoperability features described further herein, such as biller directory replication, biller directory synchronization, publishing of updates from auxiliary systems to the biller directory341and vice versa, etc.

As shown, the biller computing system304includes a biller experience circuit306and biller APIs310. The biller experience circuit306is structured to authorize the biller exchange computing system330to enroll/create billing relationships for customers, respond to bill presentment requests, and receive and post payment transactions. In some embodiments, the biller experience circuit306is structured to generate biller registration requests for the biller exchange computing system330, initiate biller data propagation or synchronization activities to synchronize data with the biller exchange computing system330, etc. Additionally, the biller computing system304can include various data storage entities configured to store information, such as the tokens generated by token generator339. The biller APIs310are structured to allow external systems to access these example functions.

As shown, the financial institution computing system320includes a biller management circuit329and financial institution APIs322. The biller management circuit329is structured to manage requests for the biller exchange computing system330to enroll/create billing relationships for customers, generate bill presentment requests, and initiate payment transactions. In some embodiments, the biller management circuit329is structured to generate financial institution registration requests for the biller exchange computing system330, initiate financial institution data propagation or synchronization activities to synchronize data with the biller exchange computing system330, etc. The financial institution APIs322are structured to allow external systems to access these example functions. Additionally, the financial institution computing system320can include various data storage entities configured to store information, such as the tokens generated by the token generator339.

As shown, the biller exchange computing system330includes exchange APIs332, a customer management circuit336, a registration circuit338, a token generator339, an exchange data vault340, an exchange dashboard346, and a publication circuit342. In some embodiments, the biller exchange computing system330may interact with one or more third-party payment processors350communicably connected to the customer management circuit336.

The customer management circuit336is structured to enable billing relationships and enrollment for the banking billers305and financial institutions321. For example, the customer management circuit336may participate in the various data acquisition sequences illustrated further herein.

The registration circuit338is structured to register billers305in response to biller registration requests received from the biller computing system304. In some embodiments, the registration circuit338is structured to register financial institutions321in response to requests received from the financial institution computing systems320. According to various embodiments, these processes can include creation and updating of registry information in the exchange data vault340.

The token generator339is structured to route tokens and authorization requests between the biller computing system304and the financial institution computing system320. Advantageously, in some embodiments security of sensitive information is increased such that the biller computing system304is structured to generate and manage authorization tokens and the biller exchange computing system330passes along requests and information without storing the tokens.

The publication circuit342is structured to enable synchronization of data, such as registry information, among the various systems, as described further herein.

The exchange APIs332are structured to enable the above functions of the biller exchange computing system330. For example, the exchange API332may be structured to receive messages from various systems via their respective APIs (e.g., from the biller APIs310, financial institution APIs322, biller processor APIs352, bill pay user financial institution API356, etc.) and to send messages thereto, as shown in various sequence diagrams illustrative of example embodiments and accompanying the present disclosure.

Referring now toFIG.4,FIG.4is a data flow diagram of a detailed example bill payment computing environment400using biller exchange computing systems330and methods applicable to the example bill payment infrastructures. At a high level, block401represents multiple financial institutions that are members of the exchange and that provide online bill pay services to customers. Block380on the right represents multiple off-us biller entities that may send one or more bills to the customer. The biller exchange computing system330at the center enables various interactions (as illustrated by solid and dashed line connections according to the legend), including real-time interactions, between the customer side and the off-us biller side, including, for example, allowing the customer to make inquiries of the off-us biller or bill data and pay the bill. The real time interactions may also include allowing the off-us biller to deliver bills and receive payments from the customer. In some implementations, the customer may request a previous bill or invoice issued by the off-us biller, besides inquiring about existing bill(s).

Turning first to the customer side included in the block401, a customer may access a bill pay mobile/online banking its account with a biller via a user computing device354. The customer's account may be held by one of the financial institutions321, each having an associated computer system320(FIG.3).

The customer may use the user computing device354to access user interfaces and features related to the operations of the payments engine of the present disclosure. For example, the customer may use the user interface to access a consolidated view of billers and products associated with the customer as well as account status for accounts of the customer that correspond to the products (e.g., credit cart, mortgage, consumer credit account at a retailer, etc.) The features may include real time inquiry of account status, statements, etc.; a timeline of scheduled payments (e.g., for a selectable time period, for selectable multiple billers, etc.); a timeline showing scheduled payments relative to source account balance(s), etc.

In another example, the customer may use the interface to retrieve biller information from a centralized directory and/or to provide instructions to add a new biller, product, etc. The customer may use the interface to invoke a customer to biller enrollment request, to perform biller lookup and selection from centralized directory, to terminate enrollment, and/or to request a new token to be generated if a customer's account (e.g., source account or target account) is compromised. When the customer invokes a biller enrollment process, the access process may redirect (at355) the access request to the computing system320of another financial institution321for OAuth enrollments, as described further herein. Further, in some circumstances, the customer and the financial institutions321may complete some or all on-us billings within the computer system320of one financial institution321. In some circumstances, OAuth may be used to obtain account information from off-us billers. For example, if the customer holds a checking account at a Bank1and has a mortgage with Bank2, OAuth may be used to obtain mortgage account information from Bank2. For on-us banking billers, biller registration information may be provided to the on-we biller directory342at operation408. Hence, in the above example, Bank2may provide information about its on-us billers to the on-we biller directory342, such that the information is available to Bank1when the customer wishes to make a payment, for example.

In yet another example, the customer may use the interface to perform invoice inquiry (e.g., to request a bill or balance information from a particular biller, to request invoices due in a particular time period, etc.). Advantageously, invoice inquiry is performed in an interoperable fashion using the biller exchange computing system330. More generally, the interfaces rendered to the customer may be structured to present information delivered from one or more billers to the consumer (e.g., account status, account information, login information, balances, invoices, transaction history, etc.).

In yet another example, the customer may use the interface to perform and/or schedule payments for one or more billers. Advantageously, payment transactions are initiated in an interoperable fashion using the biller exchange computing system330. In one example embodiment, the customer may use the interface to complete a payment. The payment transaction may be generated by the one or more APIs (e.g., the APIs332, etc.) based on payment data pre-populated via an invoice inquiry API message received from a biller computing device via biller API386.

The bill payment computing environment400enables real-time interactions between an off-us biller382and the customer using the user computing device354. To achieve such functionality, electronic interconnection between the off-us biller382and the financial institutions321, and between the off-us biller382and the exchange dashboard390of the biller exchange computing system330need be established. The relationship establishment may be achieved at the register operations416and418, which show two example biller registration processes. In the registration operation414, the biller registers with the financial institution computing system320of one of the financial institutions. As previously indicated, financial institutions typically have an array of off-us banking billers (e.g., a utility company that has an account at the financial institution) to whom they make payments on behalf of other customers (e.g., a residential customer of both the utility and the financial institution). Such billers may already be in the biller directory of the respective financial institution computer system320. At operation406, the biller registration information stored in the biller directory of the financial institution computing system320may be synchronized with the biller registration information stored in the biller exchange computing system330.

At registration operation418, the biller registers directly with the biller exchange computing system330. For example, if a biller does not have an account with any of the financial institutions that are members of the consortium (off-us non-banking biller), then the biller may register directly with the biller exchange computing system330. The registration circuit338(FIG.3) is structured to register billers305, in response to biller registration requests received from the biller computing system304. In some embodiments, the off-us biller382may have real-time interactions with the biller exchange computing system330via the exchange dashboard346, after completion of registration for example.

According to various embodiments, these processes can include creation and updating of registry information in the exchange data vault340. For example, the registry information regarding financial institutions (e.g., financial institutions321and billers305) can include financial institution names, identifiers, routing numbers (e.g., routing transit numbers (RTN), Swift network identifiers, etc.), account information, etc. In some embodiments, the exchange data vault340also includes information about the API functions exposed by the biller computing system304or the financial institution computing system320to the biller exchange computing system330. For example, the biller exchange computing system330may store version information, function definition libraries, parameter data types, etc. This information can be accessed by the biller exchange computing system330when calling the public functions of the respective system's API to route requests, data, signals, etc.

In some embodiments, the off-us billers may enable various processes336via its APIs332. These processes336may include operations to enroll customer to biller, to inquire biller or bill, to pay the biller, and/or to deliver an invoice or bill. Correspondingly, the biller exchange computing system330may receive requests of these processes336via the exchange dashboard390and return responses to such requests to biller management circuit329associated with the financial institutions321.

Generally, as with the financial institutions321, when the billers380become members of the consortium and register with the biller exchange computing system330, these entities provide a one-time initial data load to populate the exchange data vault340with registry information, at operation420. Subsequently, these entities can provide incremental data updates. These processes are managed by the publication circuit342of the biller exchange computing system330, at operation422.

For example, for a one-time data load, the publication circuit342can be configured to receive data in a suitable format, such as a SQL record set, a text file, an Excel file, etc. and execute a series of SQL commands to populate the exchange data vault340with this data. To manage incremental data loads, publication circuit342can be configured to receive registry data updates from the biller computing system304or the financial institution computing system320in a suitable format, such as SQL record set, a text file, an Excel file, etc.

In some embodiments, rather than receiving flat files or record sets, the publication circuit342can be coupled to a web server and/or can be otherwise configured to receive and decode registry updates as interface messages, such as web service messages in a suitable format (e.g., JSON, REST, etc.). The respective APIs of the source systems can be configured to “push” this data or to respond to the “pull” requests from the exchange APIs332of the biller exchange computing system330. For example, in some embodiments, the publication circuit342can be configured to call a public function of the biller APIs308and/or the financial institution APIs322to request updated data. In some embodiments, the biller computing system304or the financial institution computing system320can be configured to call a public function of the exchange APIs332to “push” the data to the biller exchange computing system300.

In some embodiments, the publication circuit342is structured to interpret (decode, parse, extract, etc.) the data received in a web service message according to a pre-determined format, which may include pre-defined field separators, field definitions and labels, field lengths, data types, etc. The decoded data can be saved, as a registry update, in the exchange data vault340.

Referring further toFIG.4, at402,404, and414, further details of an API connection between the computing systems304of the billers381, the computer systems320of the financial institutions321, and the biller exchange computing system330are shown. The API connection includes APIs310,322,332the computing systems304of the billers381, the computer systems320of the financial institutions321, and the biller exchange computing system330, respectively. Each of the APIs310,322,332provides access to a set of services/processes that may be accessed by appropriate function calls, including enroll customer to biller process, inquire biller or bill process, pay biller process, and deliver invoice process.

Referring first to the enrollment process, this process is shown in further detail relative toFIG.7A-7E, which show detailed example sequences of API function calls. More generally, however, in order to enable a biller/financial institution relationship, where the biller holds an account at a financial institution for receiving payment and the payer holds an account at another financial institution for initiating payment, the biller exchange computing system330is configured to manage requests for the biller exchange computing system330to enroll/create billing relationships for customers. In some embodiments, enrollment is a real-time transaction.

In an example embodiment, the customer management circuit336of the biller exchange computing system330can be structured to receive, from a first computing system (e.g., the financial institution computing system320) associated with an originating deposit financial institution (e.g., the financial institution321), an electronic enrollment request. The request comprises identification information associated with a receiving deposit financial institution (e.g., biller305).

For each of the financial institution321and biller305, the biller exchange computing system330can be structured to generate a secure enrollment record. In an example embodiment, the relationship between the financial institution321and the biller305is created using an OAuth protocol. OAuth (Open Authorization) is a standard for token-based authentication and authorization on the Internet. OAuth is used for access delegation and may be used as a way for internet users to grant websites or applications access to their information on other websites without giving them the passwords. In the context of the present arrangement, OAuth is used as a way for customers to grant online banking websites access to their information on biller websites without giving the financial institution their passwords to the biller websites. In some embodiments, the access given via OAuth is limited access in the sense that the functions the customer may be able to perform via online banking may be made more limited than if the customer accessed the biller website directly. In one example embodiment, financial institution321may want to receive access to information managed by the biller computing system304—for example, to see a bill, to see when a payment is due, or to access other services supported by biller APIs332. However, the customer may need to access the biller website directly if the customer wishes to perform other functions, such as making changes to services that the customer receives from the biller. The scope of access may be represented by one or more scope variables that may be associated (e.g., stored relationally to) each OAuth token (for example, in the exchange data vault340of the biller exchange computing system330). In some embodiments, the OAuth token is extended (customized) to include further information, such as a customer identifier, source system URL, a biller's product identifier or other abstracted account information, target system (biller or biller processor computing system) URL, payment information (e.g., a monthly payment amount, an auto-pay amount, a pre-set additional monthly principal payment for installment loans, etc.), custom security policy information required by the biller (e.g., customer challenge questions and answers, customer PIN code, etc.), a token expiration data field such that the token is a time-limited token, etc. Thus, the augmented OAuth token may be used for customer account recovery, to identify the biller account and schedule payments, and to support additional biller-specific authentication requirements. In some embodiments, the augmented OAuth token is a self-encoded OAuth token. In some embodiments, the augmented OAuth token is a self-contained way of transmitting data between the source (e.g., customer financial institution) and target (e.g., biller processor or biller financial institution) systems such that the number of copies of the token saved in memory can be minimized.

Further, access privileges given via OAuth may be revoked in response to receiving customer instructions to terminate a customer-biller relationship. For example, the customer may use a user interface of an online banking website to revoke access by the biller exchange computing system330to one or more biller websites. In some embodiments, the customer uses a user interface provided by the biller exchange computing system330, and the biller exchange computing system330is structured to terminate the customer-biller association (e.g., by marking an electronic mapping relationship as terminated, expiring the token, etc.) and generate an electronic notification for transmission to the biller. In some embodiments, the customer uses a user interface provided by the biller's online platform to terminate the customer-biller association, and the biller exchange computing system330is structured to receive an electronic access revocation message from the biller's computing system and, based on the message, terminate the customer-biller association.

The customer management circuit336can be structured to collect authentication data for the biller305. The authentication data can include identification information of the biller305, such as IP address, MAC address, entity name, entity identifier, etc. In some embodiments, this information can be provided by the exchange data vault340and is browsable using the interface of the first computing device. The authentication data can further include information specific to the relationship between the financial institution321and biller305, such as account number, a proxy/alias for an account, etc.

In response to receiving the authentication data, the customer management circuit336can be structured to transmit the authentication data to the biller computing system304. The biller computing system304can verify the authentication data (for example, by querying its internal systems). In some embodiments, the biller computing system304can generate a one-time authorization code and send it to the financial institution computing system320via the biller exchange computing system330. The financial institution321may be presented with a user interface control requiring the financial institution321to enter the one-time authorization code to confirm the identity of the financial institution321before verification is completed.

Once verification is completed, the customer management circuit336can be structured to transmit a request for a token to the biller computing system304and to cause the biller computing system304to generate a token using the token generator339. The token can include de-identified (obscured) sensitive information, such as account number, login credentials, financial institution identifier, biller identifier, and other authorization information. The token is subsequently used during bill inquires and payment transactions to verify that a valid relationship exists between the biller305and the financial institution321indicating that the financial institution321is willing to send payments and biller305is willing to receive payments.

The customer management circuit336can be structured to generate or cause another computing system to generate a financial institution enrollment record to supplement the tokenized information. The financial institution enrolment record may include the token and may be transmitted from the biller computing system304to the biller exchange computing system300by calling a public function of the exchange API332. In some embodiments, enrollment records are product- (account-) level records rather than financial institution-level records, as shown at514ofFIG.5.

The customer management circuit336can be structured to transmit a first copy of the token to the financial institution computing system320and/or direct the biller computing system304to retain a second copy of the token. Each respective entity can save its copy of the token in a data store associated with the entity, such as non-volatile memory, a token vault, etc. According to various embodiments, the data store of each respective entity may include a mapping data structure (such as a table) that correlates a reference to a specific system (such as a URL, an IP address, a MAC address, a network path, etc.) with biller financial institution relationship information (such as an account handle, user name, identification number, account number in combination with a reference to a specific system, email address, social media handle, name, telephone number, email address, business address, etc.) In some embodiments, the data store comprises a data structure for storing a timestamp for each token(s). The token(s) may expire and be replaced with new token(s) at periodic intervals, such as, for example, every week, every month, every quarter, every time a token has been used, after a set number of times a token has been used (for example, between one and ten times), etc. In some embodiments, these parameters are encoded in the token instead or in addition to being stored relationally to the token.

Further with respect to402,404, and414, the customer management circuit336can be structured to enable bill inquiries and to transfer payments. In some embodiments, the customer management circuit336can be structured to allow a customer to specify how the customer would like to configure the payments experience after a customer enrolls with a biller. The customer management circuit336may cause the biller exchange computing system330to generate a user interface and render the user interface to the computing device354of the customer. The user interface may be structured to enable the customer to specify whether the customer would like to initiate payments (e.g., on demand, on a particular day of the month, etc.) or if the customer would like payments to be initiated in response to requests for payments received via the financial institution API322. In some embodiments, the customer management circuit336is structured to store an indicator of customer preference in memory. Based on the indicator and/or the information received via the financial institution API322(e.g., invoice information, such as amount due, payoff amount, due date, etc.), the biller exchange computing system330may be structured to generate a payment transaction for the customer's review and transmit the payment transaction to computing device354of the customer for approval. In some embodiments, multiple transactions may be presented to the customer for approval. In one example implementation, the transactions may be presented as a sequence of screens, one per transaction, on a mobile device of the customer. The biller exchange computing system330may comprise functionality to determine, based on the customer's interaction with each screen item, whether a transaction is approved. For example, in one embodiment, swiping in a first particular manner (e.g., swiping up, swiping to the right) may be indicative of approval, swiping in a second particular manner (e.g., swiping left) may be indicative of a instructions to delete the pending transaction, and swiping in a third particular manner (e.g., swiping down) may indicate instructions to flag the transaction for further review by the customer.

In response to an electronic message or an interface interaction indicating approval of the transaction, the biller exchange computing system330may initiate a payment transaction. In some embodiments, the payment transaction includes electronic instructions to transfer funds from a source account associated with the customer to a target account associated with a biller (e.g., the financial institution321). In some embodiments, the payment transaction includes electronic instructions that may be transmitted to a clearance and settlement computing system. In some embodiments, the biller exchange computing system330further includes functionality to allow a customer to revoke a pending payment transaction and/or reverse a completed payment transaction. For example, a list of recent transactions may be presented as a sequence of screens, one per transaction, on a mobile device of the customer. The biller exchange computing system330may comprise functionality to determine, based on the customer's interaction with each screen item, whether a transaction should be revoked or reversed. In one example embodiment, swiping left may be indicative of instructions to revoke or reverse the transactions. The biller exchange computing system330may comprise functionality to display to the customer, via the user interface, a confirmation screen confirming customer instructions to revoke or reverse the transaction. In some embodiments, revocation or reversal functionality is available only within a predetermined amount of time from performing the payment transaction (e.g., 2 hours, close of business, 24 hours, etc.).

Referring further toFIG.4, at420and424, a clearing process is shown. After a payment transaction is initiated, in some embodiments, the biller exchange computing system330is structured to transmit transaction data to a clearinghouse computing system326for clearance and settlement. According to various embodiments, the clearinghouse computing system326can use various clearance and settlement platforms, such as Zelle®, ACH, TCH RTP®, etc.

Referring now toFIGS.5and6, example data model diagrams are shown for various aspects of the biller exchange computing systems and methods. A biller exchange computing system330ofFIG.3includes a centralized biller directory341. The biller directory, represented, for example, inFIG.5by data storage entity504and its related entities, may include, in a standardized format identification data for all billers and/or their associated biller processors, receiving financial institutions (e.g., RDFI) and other payment routing information needed by the payments engine to route payments appropriately. Various other systems of the payment infrastructure may maintain their own copies of the biller directory, which may be maintained via replication and/or synchronization processes described further herein. To that end,FIG.5is a data model diagram of one aspect of an example data store used in the example biller exchange computing environment shown inFIG.4.FIG.6is a data model diagram of another aspect of an example data store associated with a biller computing system for use in the example biller exchange computing environment shown inFIG.4.

As shown,FIG.5shows a relational data model diagram for a data store associated with the biller exchange computing system330, such as the exchange data vault340and/or a biller directory341. The data of the example embodiment is stored and available for inquiry by calling public functions of the exchange API332of the biller exchange computing system330. For example, the data can include data dictionary/registry information for the biller305(at504,506,510,512) and/or financial institution321(at508), customer information (at514and516) and payment transaction information (at518).

In some embodiments, the data further includes API library information for the respective entity (at508). More specifically a biller may hold an account at a receiving financial institution, which may be enrolled in the exchange. The financial institution may operate a computing device that may have a financial institution API (e.g.,322ofFIG.3) deployed to or accessible by that computing device. The API library may be identified by a unique address, such as an API URL stored relationally to the financial institution and biller information as shown at508. When a customer requests an invoice, schedules a payment, requests enrollment, or otherwise invokes functionality that requires communication with the biller's financial institution, the payments engine (e.g., of the biller exchange computing system330ofFIG.3) may query the data store to determine the API URL based on customer identity and the token (at514), based on enrollment data (at510), and/or based on biller information (at504). In some embodiments, these items are determined by decoding the token, which may contain this information. The payments engine may then use the API URL to send payment transactions, enrollment messages, etc. to the financial institution on behalf of the customer.

In some embodiments, the payment transaction information518is exposed, via the API, for mining historical trends, predicting future payments, etc. The information can be exposed in a de-identified form and/or may require a token to be accessible. For example, in some embodiments, the biller computing system304and/or the financial institution computing system320may be required to provide the token generated when the biller/FI relationship was registered via the biller exchange computing system330in order to access historical payment information for data mining.

In some embodiments, payment transaction information518is aggregated for the purposes of initiating transactions, posting transactions, clearance and settlement, etc. For example, pending transactions can be sent, through the biller exchange computing system330, in batches to the systems responsible for performing the respective activities (e.g., the biller computing system304, the clearinghouse computing system326, etc.).

As shown,FIG.6shows a relational data model diagram for a data store associated with a biller computing system304, according to an example embodiment. In some embodiments, the data is stored in a data storage entity associated with the biller computing system304. In some embodiments, the data is part of the exchange data vault340ofFIG.5. For example, in some embodiments, biller account information stored in the exchange data vault340includes the items shown at502ofFIG.5and522ofFIG.6.

While the embodiments ofFIG.5andFIG.6are shown as relational databases, other embodiments are contemplated, such as a multi-dimensional database, an online analytical processing (OLAP) cube, a distributed ledger, a collection of cross-referenced flat files, etc.

Referring now toFIGS.7A-10B, computing systems sand sequence flow diagrams that illustrate various aspects of the payments engine are shown.FIGS.7A-7Eshow the computing systems involved in the biller enrollment process, according to an example embodiment, and APIs therefor. During the biller enrollment process, a biller and/or the biller's financial institution sign up to the exchange and are mapped to a particular customer and/or account (product).FIGS.8A-8Cshow the computing systems involved in the bill inquiry and presentment process, according to an example embodiment, and APIs therefor. During the bill inquiry and presentment process, a customer receives (either in a push or pull fashion) an invoice from a biller that is signed up to the exchange.FIGS.9A and9Bshow the computing systems involved in a payment process, according to an example embodiment, and APIs therefor. During the payment process, a payment is originated from an originating financial institution to the receiving financial institution, where the receiving financial institution is determined by the payments engine based on information contained in the biller directory and where the payment transaction may be based on data from a biller invoice routed through the exchange.FIGS.10A and10Bshow the computing systems involved in a biller directory replication and/or synchronization, and the APIs therefor. During the biller directory replication and/or synchronization, payment routing information (such as biller information, financial institution information, biller processor information, etc.) is standardized across computing systems of the participants in the payments ecosystem.

In the example embodiments ofFIGS.7A-10B, data is exchanged between various computer-implemented entities shown inFIGS.1-6. For example, the customer701of the sequence diagrams refers to the computing device354of the customer101of the originating financial institution (herein, although the acronym “ODFI” is used, it will be understood that payments may also be made via payment rails other than ACH—for example, via TCH RTP®). The ODFI bill page702refers to a bill page web interface provided by the computing system320of the ODFI. The ODFI computing system721refers to other, predominantly backend, operations performed by the computing system320of the ODFI. The biller exchange computing system741refers to the biller exchange computing system330, including APIs provided by the computing system330. The RDFI computing system761refers to the computing system320of the receiving financial institution, including APIs provided by the computing system320. The biller771refers to the biller computing system304used by the biller, including APIs provided by the computing system304. In some embodiments, the computing systems further include biller processor computing systems. In embodiments where biller processor computing systems are not shown, one of skill will appreciate that biller processor computing system functions may be performed by the exchange computing systems, biller computing systems, and/or the biller's financial institution computing systems.

As shown, data is exchanged between the entities ofFIGS.7A-10Busing function calls according to an API of each respective computing system. For example, function calls made to the ODFI computing system721are made by calling the public functions exposed by the financial institution API322to external systems with which the ODFI computing system721is communicatively coupled. Function calls made to the biller exchange computing system741(e.g.,712,744, etc.) are made by calling the public functions exposed by the exchange API332to external systems with which the biller exchange computing system741is communicatively coupled. Function calls made to the RDFI computing system761(e.g.,726, etc.) are made by calling the public functions exposed by the biller API310to external systems with which the RDFI computing system761is communicatively coupled.

FIGS.7A-7Eshow the computing systems involved in the biller enrollment process, according to an example embodiment, and APIs therefor.FIG.7Ashows the computing systems involved in the biller enrollment process facilitated by the biller exchange computing system.FIG.7Bis a sequence flow diagram for biller enrollment using an example API, according to an example embodiment.FIG.7Cis a sequence flow diagram illustrating an enrollment operation with browser to browser customer consent.FIG.7Dis a block diagram illustrating an enrollment operation with server to server token retrieval for preparing the example data store ofFIG.5.FIG.7Eis a block diagram illustrating an enrollment operation integrating small financial institutions or billers or both for preparing the example data store ofFIG.5.

InFIG.7A, the infrastructure includes consumer7001operating a consumer computing device, consumer's financial institution7021operating a financial institution computing device, biller7071operating a biller computing device, biller processor7081operating a biller processor computing device, and biller financial institution7061operating a biller financial institution computing device. One of skill will appreciate that computing devices may be server devices, client devices, mobile devices, etc. as appropriate. The participants in the payments ecosystem share information and perform transactions enabled by the biller exchange computing system7130. In an example embodiment, the biller exchange computing system7130may be operated by a consortium of financial institutions, and the consumer's financial institution7021, biller's financial institution7061, biller processor7081, etc. may be members thereof.

The participants in the payments ecosystem exchange data and perform transactions via a set of APIs that support interoperability among the participant systems. More particularly, in an example embodiment, the consumer7001may use the consumer computing device to initiate the process of adding a consumer's biller7071via the exchange, thereby creating a new mapping between the consumer7001and one or more consumer accounts with the biller7071. For example, a user with a new mortgage and credit card account at Bank A may hold a checking account at Bank B. The user may use Bank B's Bill Pay user interface to set up automatic bill inquiry, bill presentment, and payment features to Bank A using the exchange. The new mapping is secured using tokenization—for example, via an OAuth token, which may include or be stored relationally to customer information, biller identifier, biller account identifier, biller processor identifier, OAuth authorization scope information, pre-scheduled payment information, etc. Once a mapping is established, the biller7017is considered enrolled (relative to the consumer and the consumer's particular product with the biller). Some aspects of an example API library and EDI messages related thereto are discussed in the table below:

TABLE 1Example EDI Messages and API Functionality (Enrollment)APIIdentifierDescriptor7010Consumer adds a Biller as a Payee on their FI's computing system's Bill Pay UI7020Consumer's FI computing system checks its Biller Directory received from On-We Exchange computing system to retrieve the OAuth Authorization URL andredirects Consumer there7030Consumer provides username/password credentials on Sign-On page hosted byBiller Processor computing system7040Credentials are forwarded and validated by Biller computing system, whichreturns the eligible account(s) that Consumer can authorize consent on7050Consumer selects the account(s) for the scope of OAuth authorization consent(e.g., read, write, selectively enabled read/write by functionality, selectivelyenabled read/write by data element access level/confidentiality, etc.)7060Biller Processor computing system generates Authorization Code and maps it toConsumer's selected account(s) scope of consent7070Biller Processor computing system navigates User back to Bill Pay return URL,along with Authorization Code7080Consumer's FI computing system exchanges Authorization Code to AccessToken with Biller's FI computing system by invoking On-We Exchange's“Enroll” API, passing Biller ID and the Authorization Code received from BillerProcessor computing system7090On-We Exchange computing system processes the “Enroll” request, internallymaps the Biller ID received to the Biller's FI, and invokes Biller's FI compingsystem's “Enroll” API (forwarding the Biller ID and Authorization Codereceived)7100Biller's FI computing system forwards the Authorization Code to BillerProcessor computing system for validation7110Biller Processor computing system validates the Authorization Code received7120If validation is successful, Biller Processor computing system generates OAuthAccess Token to swap with the Authorization Code7130Biller's FI computing system returns the Access Token in its “Enroll” APIresponse back to On-We Exchange7140On-We Exchange computing system forwards the same result back on its“Enroll” response to Consumer's Bank computing system7150Consumer's FI computing system Bill Pay saves and binds the Access Token tothe Biller and Consumer7160Consumer's FI computing system Bill Pay displays a successful Biller enroll toConsumer message via UI

InFIG.7B, the customer701sets up bill pay for an off-us non-banking biller. In other words, the customer uses a first (ODFI) bank, and the biller uses a second (RDFI) bank. As shown, a biller processor is not used, but one of skill will appreciate that some of the functions performed by the computing systems shown may be performed by a biller processor computing system and/or a biller processor's financial institution computing system. The customer701may search for a known biller on the ODFI bill pay page702at step704. At step706, the customer701may submit a request to add an on-we biller to the customer's list of payees on the ODFI bill pay page702. The ODFI bill pay page702forwards the biller enrollment request from the customer701to the ODFI computer system721at step708. The ODFI computing system721confirms the on-we biller at step710and enrolls the customer701to the biller profile in the biller exchange computing system741at step712. At step716, the biller exchange computing system741returns the biller RDFI OAuth URL to the ODFI721, which further returns the biller RDFI OAuth URL to the ODFI Bill pay page702. Afterwards, on the ODFI Bill pay page702, the customer701may redirect the customer701to RDFI authentication page at718and access RDFI761. The RDFI761may display the RDFI login page to the customer701at step720.

After authentication, the customer701may then interact with RDFI761through the biller exchange computing system741. For example, the customer701may request authentication at step722. The RDFI761may then display authorization selection page to the customer701at step724. The customer701may submit selected on-we biller authorization at step726. The RDFI761may then generate authorization code at step728. At step730, the RDFI761may save the mapping of the authorization codes. At step732, a one-time OAuth authorization code is returned to the ODFI bill pay page702.

At step734, the ODFI bill pay page702passes the OAuth authorization code to the ODFI721. The ODFI721may enroll the customer701to the biller771in the biller exchange computing system741at step736. In some embodiments, the biller exchange computing system741may forward the customer enrollment to the RDFI761at step738, for example, without saving or otherwise interacting with the one-time authorization code. After validation, the RDFI761may validate the authorization at step740and generate an OAuth token at step742. The RDFI761returns the OAuth token to the biller exchange computing system741at step744. The biller exchange computing system741provides a live biller-customer OAuth token at step746and forwards or returns the OAuth token to the ODFI721at step748. The ODFI721saves the customer biller enrollment token at step750and sends a confirmation of success of customer-biller enrollment notification to the ODFI bill pay page702at step752. At step754, the ODFI bill pay page702displays an enrollment success notification to the customer701.

FIG.7Cis a block diagram illustrating an enrollment operation with browser to browser customer consent for preparing the example data store ofFIG.5. As shown, a biller processor is not used, but one of skill will appreciate that some of the functions performed by the computing systems shown may be performed by a biller processor computing system and/or a biller processor's financial institution computing system. At step1201, the customer may add a biller associated with a different financial institution using a client end bill pay user interface. At step1202, the bill pay user interface redirects the customer to an OAuth sign-on web-site of the biller's financial institution. For example, the user interface provides a biller's OAuth resource application sign-on or consent site URL. At step1203, the customer701may sign on to the biller's financial institution.

At step1204, the customer701may consent to allow his own financial institution to access the account created in the sign-on financial institution. After signing on and providing the consent at the OAuth web site, the resource application of the biller's financial institution may generate a one-time authorization code at step1205. The resource application may save the consent from the customer701for future reference at step1206. The customer701is redirected and returned to the bill pay user interface with authorization code at step1207. As such, both the client's bill-pay site and the biller's OAuth sign-on site may whitelist the URLs therebetween, allowing OAuth to redirect information flow between these two endpoints. In some embodiments, the redirecting URLs may be shared between the end points through new data attributes in the biller directory exchange systems as disclosed herein.

FIG.7Dis a block diagram illustrating an enrollment operation with server to server token retrieval for preparing the example data store ofFIG.5. As shown, a biller processor is not used, but one of skill will appreciate that some of the functions performed by the computing systems shown may be performed by a biller processor computing system and/or a biller processor's financial institution computing system. In this embodiment, a customer may be enrolled via the client application to associate with a biller using an OAuth authorization code at step1221. For example, this may be achieved through both the client bill pay application and the biller resource application that are integrated via an enroll API at the biller exchange computing system as disclosed. The biller exchange computing system may abstract and mediate the OAuth Token Retrieval request from the Client Bill Pay Application to the Biller Resource Application end points. As such, the one-time integration (enrollment) with the biller exchange computing system provides the technical benefit of abrogating the need for each of the customer and biller's end point applications to implement multiple direct backend authorizations with each other every time a customer performs a presentment inquiry, schedules a transaction, etc. At step1222, a second enrollment process, which includes swapping of a temporary authorization code for a token, can also be performed without including biller information in the API messages.

At steps1223-1225, the resource application may be in connection with a public enroll API that allows the biller exchange computing system210to pass the token retrieval request to biller. In such a situation, the biller exchange computing system210may forward the OAuth token returned from this biller API to the client bill pay application. At step1223, authorization code is validated by the resource application. At step1224, the resource application may generate an OAuth token in response to a successful validation of the authorization code. At step1225, the generated OAuth token may be tied to the biller for future transaction processes. At step1226, the generated OAuth token is returned through the biller exchange computing system210to the next step. At step1227, the OAuth token is returned, in a forwarding manner, to the client application. The client application then saves the OAuth token to note the customer enrollment with the biller at step1228. In this manner, the biller exchange computing system may bridge the token requests and responses between the client application and resource application, facilitating real-time operations.

FIG.7Eis a block diagram illustrating an enrollment operation for integrating small financial institutions or billers or both for preparing the example data store ofFIG.5. As shown, a biller processor is not used, but one of skill will appreciate that some of the functions performed by the computing systems shown may be performed by a biller processor computing system and/or a biller processor's financial institution computing system.

As shown in the embodiment ofFIG.7E, the biller exchange computing system API1263performs some or all of the token generation functions that may ordinarily be performed by biller processor computing systems for larger billers (e.g., as shown inFIG.7A). Often, small financial institutions or billers may not have adequate resources or technology setup to implement an OAuth API and/or tokenization infrastructure.FIG.7Eprovides another embodiment of enrollment token generation supported by the biller exchange computing system for such situations. A customer may access the biller exchange computing system API1263via its bill pay API1261associated with the customer's financial institution. The biller exchange computing system API1263may handle the responsibilities of OAuth authorization code and token generation in place of a tokenization infrastructure of a biller processor computing system. For example, a customer device may initiate a small biller enrollment process. The customer's financial institution may send an electronic message that includes a customer signature payload. The customer signature may comprise information needed to identify the customer and/or the customer's financial institution to the biller. The message may be routed through the exchange computing system API1263. The exchange computing system API1263may, in response to a validation request, validate a signature at1269(e.g., confirm that a customer is associated with the customer's financial institution), generate an authorization code at1271, and sign the generated authorization code1273. The authorization code may be forwarded to a biller computing system, where the authorization code may be authenticated at1277(automatically or by an operator) to confirm that the biller will accept electronic remittances initiated by the customer's financial institution. If these operations are performed automatically, the biller may use the biller API1265to perform authentication of the authorization code.

The biller may use the biller API1265to invoke an API exposed by the biller exchange computing system at step1277. The biller exchange computing system may swap out the authorization code for an access token (e.g., one generated by a token generator) and send the access token back to the biller computing system, where the token may be stored in storage media relationally to the customer and/or biller account information. This allows for biller account selection at step1279. The access token may be a numeric or alphanumeric entity (including special characters) and may include a biller identifier, a customer identifier, a biller's product identifier, payment information (e.g., a monthly payment amount), custom security policy information required by the biller (e.g., customer challenge questions and answers, customer PIN code, etc.). In some embodiments, the token does not necessarily include the customer's login information for the biller's computing system, but may be used as a secondary authentication mechanism through the biller exchange computing system in the event the customer forgets the login credentials and is unable to reset them via the biller's computing system. For instance, the token may be decoded to provide challenge questions to the customer and request responses, to request a PIN code, etc. This provides the technical benefit of augmented system and data security.

The bill pay API1261also saves the token relationally to the customer and/or biller identifier for future processing at step1287and sends a confirmation notification to the customer701at step1289.

FIGS.8A-8Cshow the computing systems involved in the bill inquiry and presentment process, according to an example embodiment, and APIs therefor.FIG.8Ashows the computing systems involved in the bill inquiry and/or bill presentment process facilitated by the biller exchange computing system. Bill inquiry may be initiated by the consumer. Bill presentment may be initiated by the biller.FIG.8Bis a sequence flow diagram for bill inquiry and/or bill presentment using an example API, according to an example embodiment.FIG.8Cis a sequence flow diagram for the bill presentment process using an example API, according to an example embodiment.

InFIG.8A, the infrastructure includes consumer8001operating a consumer computing device, consumer's financial institution8021operating a financial institution computing device, biller8071operating a biller computing device, biller processor8081operating a biller processor computing device, and biller financial institution8061operating a biller processor computing device. One of skill will appreciate that computing devices may be server devices, client devices, mobile devices, etc. as appropriate. The participants in the payments ecosystem share information and perform transactions enabled by the biller exchange computing system8041. In an example embodiment, the biller exchange computing system8041may be operated by a consortium of financial institutions, and the consumer's financial institution8021, biller's financial institution8061, biller processor8081, etc. may be members thereof.

The participants in the payments ecosystem exchange data and perform transactions via a set of APIs that support interoperability among the participant systems. More particularly, in an example embodiment, the consumer8001may use the consumer computing device to initiate the process obtaining the latest balance, invoice, and other payment-related information from a particular biller8071. Some aspects of an example API library and EDI messages related thereto are discussed in the table below:

TABLE 2AExample EDI Messages and API Functionality (Consumer-Initiated Bill Inquiry)APIIdentifierDescriptor8010Consumer requests updated Biller info via their FI's computing system Bill PayUI8020Bill Pay retrieves the OAuth Access Token tied to the Consumer and Biller8030Consumer's FI computing system executes an “Inquire” request against On-WeExchange computing system, passing the Biller ID and Access Token8040On-We Exchange computing system processes the “Inquire” request, internallymaps the Biller ID received to the Biller's FI, and then invokes Biller's FIcomputing system's “Inquire” API, forwarding the Biller ID and Access Token8050Biller's FI computing system forwards the request to the Biller Processorcomputing system8060Biller Processor computing system validates the Access Token tied to the Billerand Consumer, and maps this to Consumer and Biller Account Number8070Biller Processor computing system retrieves the latest Biller info from the Billercomputing system8080Biller's FI computing system returns the latest Biller info to On-We Exchangecomputing system8090On-We Exchange computing system returns the latest Biller info to Consumer'sFI computing system8100Consumer's FI computing system Bill Pay displays the latest Biller info toConsumer via UI

In another example embodiment, the consumer8001may receive, via the consumer computing device, electronic notifications and invoices (e.g., as PDF documents, standardized electronic messages, etc.) from a particular biller8071. Some aspects of an example API library and EDI messages related thereto are discussed in the table below:

TABLE 2BExample EDI Messages and API Functionality (Biller-Initiated Bill Presentment)APIIdentifierDescriptor8210Biller computing system pushes updated Biller info to their Biller Processorcomputing system8220Biller Processor computing system maps the Biller and Consumer to an AccessToken8230Biller Processor computing system forwards updated Biller info to Biller's FIcomputing system8240Biller's FI computing system invokes On-We Exchange to update Biller Info toConsumer, passing the Biller ID and Access Token8250On-We Exchange computing system passes the updated Biller info to theConsumer's FI computing system8260Consumer's FI computing system Bill Pay maps the Access Token and Biller IDto its specific Consumer

InFIG.8B, the customer701inquires about a bill from the biller771. On the ODFI bill pay page702, the customer701may send request to view bill details at step802. The ODFI bill pay page702submits the request to view bill details to the ODFI721at step804. In response, the ODFI721retrieves the customer-biller OAuth token saved from previous enrollment at step806. The ODFI721may, in a continuing or a different session, send an inquiry to the exchange741at step808. The biller exchange computing system741maps the biller-customer to RDFI761and forwards the inquiry to the biller771at step812. The RDFI761validates the token at step816and maps the token to biller account at step814. The RDFI761then sends the inquiry regarding the biller account to the biller771at step818. The biller771, in response to the inquiry, may automatically and/or instantly return a result to the RDFI761at step820. The RDFI761ant the biller exchange computing system741may forward the result at steps822and824respectively, to the ODFI721. The ODFI721then displays the bill details on the ODFI bill pay page702at step826. The ODFI bill pay page702then displays the bill details to the customer701at step828.

InFIG.8C, a biller771may deliver an invoice or bill to the customer701. The process or method includes step1102where the biller771issues an invoice to an ODFI721for the customer701at an RDFI. The ODFI721looks up a corresponding customer-biller OAuth Token and delivers the invoice to the biller exchange computing system741at step1104. The biller exchange computing system741maps the biller-customer relationship to RDFI and delivers invoice to RDFI761at step1110. The RDFI761is operable to validate the token and process the received invoice at step1114. The RDFI761may then notify the customer701the billing request from the invoice data at step1116. The customer701may then pay the biller771in response to the notification received from the RDFI761at step1118.

FIGS.9A and9Bshow the computing systems involved in a payment process, according to an example embodiment, and APIs therefor.FIG.9Ashows the computing systems involved in an example payment process facilitated by the biller exchange computing system.FIG.9Bis a sequence flow diagram for payment processing using an example API, according to an example embodiment.

InFIG.9A, the infrastructure includes consumer9001operating a consumer computing device, consumer's financial institution9021operating a financial institution computing device, biller9071operating a biller computing device, biller processor9081operating a biller processor computing device, and biller financial institution9061operating a biller processor computing device. One of skill will appreciate that computing devices may be server devices, client devices, mobile devices, etc. as appropriate. The participants in the payments ecosystem share information and perform transactions enabled by the biller exchange computing system9051. In an example embodiment, the biller exchange computing system9051may be operated by a consortium of financial institutions, and the consumer's financial institution9021, biller's financial institution9061, biller processor9081, etc. may be members thereof.

The participants in the payments ecosystem exchange data and perform transactions via a set of APIs that support interoperability among the participant systems. More particularly, in an example embodiment, the consumer9001may use the consumer computing device to initiate or schedule a payment to particular biller8071. In some embodiments, a payment transaction may be based at least in part on the billing information received from the biller8071via the exchange via the bill inquiry and/or bill presentment API functions. For example, certain fields of the payment transaction, such as a payment date, payment amount, memo line, reference account number, reference invoice identifier, etc. may be pre-populated. In an example embodiment, the FI computing system of the consumer9001initiates a transmission of a remittance to the biller computing system through a payment rail, such as TCH RTP®. In some embodiments, a Credit Transfer message (PACS 008) is used to transmit remittance information. The PACS 008 message may be generated by the API according to a predetermined PACS format and further augmented with exchange-specific information indicating that the payment is enabled via the exchange. For example, the PACS 008 message may contain an indicator for financial institutions to recognize that the payment is made through the exchange, an exchange identifier, an encoded identifier of a computing resource where the biller exchange computing system9051stores the binding information for the corresponding enrollment mapping, a unique identifier assigned by the biller exchange computing system9051for a specific payment being made on a specific bill (to enable a technical benefit of the biller computing system automatically posting the payment received via the exchange to a particular invoice, etc.). The Payment Rail computing system may route the real-time payment remittance to the Biller's FI computing system as part of the PACS 008 or similar message, passing the biller id and the OAuth token in addition to the remittance data. In some embodiments, the OAuth token is included in the message. Some aspects of an example API library and EDI messages related thereto are discussed in the table below:

TABLE 3Example EDI Messages and API Functionality (Payments)APIIdentifierDescriptor9010Consumer requests to pay their Biller via their FI computing system Bill Pay UI9020Consumer can select to pay their Biller manually or automatically when updatedBiller info (invoice) is received9030Bill Pay retrieves the OAuth Access Token tied to the Consumer and Biller9040Consumer's FI computing system executes real-time payment remittance to theBiller's FI computing system through a payment rail, passing the PaymentRemittance data: Biller ID and Access Token9050Payment Rail computing system routes the real-time payment remittance to theBiller's computing system, passing the Payment Remittance data: Biller ID andAccess Token9060Biller's computing system forwards the request to the Biller Processor computingsystem9070Biller Processor computing system validates the Access Token tied to the Billerand Consumer, and maps this to Consumer and Biller Account Number9080Biller Processor computing system remits the payment to the Biller, passing thepayment data, the Consumer, and Biller Account Number9090Biller's FI computing system returns the status and result of the payment to On-We Exchange computing system and/or Payment Rail Computing system9100On-We Exchange computing system returns the payment status and result toConsumer's FI computing system9110Consumer's FI computing system Bill Pay UI displays the payment status andresult to Consumer

InFIG.9B, the customer701initiates/makes a payment to the biller771. The customer701may submit a payment to biller on the ODFI bill pay page702at step902. The ODFI bill pay page702submits the payment for the biller771to ODFI721at step804. The ODFI721confirms the on-we biller relationship at step906and retrieves the OAuth token tied to the customer701and the biller771at step908. At step910, the ODFI721sends the payment toward the biller exchange computing system741which maps the biller-customer relationship at step912. The biller exchange computing system741then forwards the payment to RDFI761at step914. The RDFI761validates the token at step916and deposits a payment to the biller771's account at step918.

At step920, the payment is posted to the biller771or a system thereof. In response, the biller771may return a payment result at step922. The RDFI761may send an inquiry for the bill details at step924. The biller771returns the inquired bill details to the RDFI761at step926. In some embodiments, the ODFI721and the RDFI761as shown inFIG.9may be the same financial institution. In such situation, the financial institution may post the payment and/or bill details internally or route roundtrip out to the biller exchange computing system741. The RDFI761then returns the payment results and bill details to the biller exchange computing system741at step928. The biller exchange computing system741forwards the payment result and bill details to the ODFI721at step930. The ODFI721returns the results to the ODFI bill pay page702at step932. The customer701may then view the payment results and bill details on the ODFI bill pay page702at step934.

FIGS.10A and10Bshow the computing systems involved in biller directory replication and/or synchronization, and the APIs therefor.FIG.10Ashows the computing systems involved in the biller registration process facilitated by the biller exchange computing system.FIG.10Bis a sequence flow diagram for a biller directory replication and synchronization process using an example API, according to an example embodiment.

InFIG.10A, the infrastructure includes biller1071operating a biller computing device, biller processor1081operating a biller processor computing device, biller and/or biller processor financial institution1061operating a computing device, and/or other financial institutions (such as other biller and/or biller processor financial institutions, consumer financial institutions, third party processors, payment rail operators, etc.) and their respective computing devices. One of skill will appreciate that computing devices may be server devices, client devices, mobile devices, etc. as appropriate.

The participants in the payments ecosystem share information and perform transactions enabled by the augmented biller directory1010. In some embodiments, the augmented biller directory1010is hosted by a biller exchange computing system (not shown). In some embodiments, the augmented biller directory1010is distributed in whole or in part across various computing systems. The augmented biller directory1010is distributed to financial institutions via data replication, data synchronization, and the like. For instance, as shown at1010, the exchange can support an aggregated and standardized biller directory comprising billers that belong to multiple different biller directory sources that may be used across the participant systems (e.g., EBIDS, Fiserv, FIS, MasterCard, etc.). Further, as shown at1020, each participant can augment the aggregated biller directory by registering additional billers associated with the participant financial institution, their associated biller processors, relational mappings therebetween, etc. As shown at1030, biller registration data can include an indicator denoting whether the biller will accept real-time or batch payments. The indicator may be used by the exchange when payments are scheduled or initiated to determine the appropriate payment rail, to build a credit transfer message, etc. As shown at1040, biller registration and/or augmentation may be performed through a user interface of a biller registration website (e.g., through data entry, batch biller data upload, etc.) and/or through an API hosted by the biller exchange computing system. As shown at1050, the augmented biller directory is distributed, via synchronization (e.g., full download) and/or replication (e.g., partial download) to the participant computing system.

InFIG.10B, the financial institution or biller771amay establish secure relationships on the biller exchange computing system741with other financial institutions771b.FIG.10Bfurther elaborates the communications420and422ofFIG.4. For one-time biller data load420, the biller771amay register with the biller exchange computing system741and allows the application to extract all biller data at step1002. The extracted biller data is then sent to the biller exchange computing system741at step1004. The biller exchange computing system741then saves the extracted biller data at step1006. For recurring biller data synchronization422, the biller771amay provide a biller update or new biller registration by adding or updating biller data at step1012. The application then sends the updated or new data to the biller exchange computing system741at step1014. The biller exchange computing system741then saves the biller data at step1016and forward the saved updated data to other financial institutions771bat step1018. As such, the updated biller account information or customer data may be published at the biller exchange computing system741per agreement.

In some embodiments, the biller data may be periodically updated, for example, through receiving incremental update records from a computing system of the biller771a. The biller exchange computing system741may maintain a cross-reference directory, which may store the biller information relationally to an immutable biller identifier generated by the biller exchange computing system computing741and/or relationally to the access tokens generated for individual customers of the biller771a. Advantageously, when biller information changes, the biller identifier and/or access tokens (or parts thereof related to biller identifying information) may remain immutable.

The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.

It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”

As used herein, the term “circuit” may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOC) circuits), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on.

The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.

An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing devices in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components), in accordance with the example embodiments described herein.

It should also be noted that the term “input devices,” as described herein, may include any type of input device including, but not limited to, a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices performing a similar function.

Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.

It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule-based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.

The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and embodiment of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.