Home » IFX Standard » IFX for EBPP

IFX for EBPP Datasheet

Background
The complex business models found in Electronic Bill Presentment and Payment (EBPP) environments create two types of data exchange requirements; the ability to capture all of the transactional data itself and the reliable coordination of the communication of that data. By definition, EBPP applications are dependent on the networks that they connect to. In order to transfer billing data from the originator through one or more service providers to the recipient, significant interactions must take place. EBPP can only work if all of the entities involved in delivering the services are able to communicate together in a reliable, flexible, economic fashion.

The participating entities can be separate financial institutions, corporations/billers, or service providers of all varieties – all of which may or may not have pre-established relationships with each other, sit within the same corporate walls, or even be located within the same country. The challenge to creating a messaging standard for EBPP is to assure the successful interoperation of all parties involved in delivering the required services.

IFX for EBPP is a cooperative industry effort between major financial institutions, service providers, and information technology partners to develop the single, open financial services industry standard for EBPP. Developed based on the experience garnered from past endeavors, the financial services industry has united to create a specification that encompasses strong design principles and real-world use case scenarios.

Why XML and IFX?
It is widely accepted that any emerging communication protocol be based on the industry leading standard for network applications, the eXtensible Markup Language (XML). XML is a format for defining, transmitting, validating and interpreting data over the Internet between applications and between organizations, and is widely viewed as the leading data exchange technology for e-commerce. XML makes it easier for companies to integrate data because, in addition to structuring data -- i.e., telling what the content is and what role the content plays, such as whether it's a heading, a footnote or just data -- XML "tags" tell a user how data is organized and how to read the information in the file.

However, XML alone does not solve all of the challenges that are faced when creating EBPP applications. The value-add of the Interactive Financial eXchange (IFX) for EBPP is the business message set that contains the data and business rules necessary to perform the required functionality of delivering bills, collecting payment and providing customer support. By standardizing both the syntax and the meaning of data exchange, the various interacting parties are assured of reliable transaction processes.

Designed for the Service Provider Model
The InteroperaBILL initiative fostered by the Banking Industry Technology Secretariat (BITS) and supported by the National Automated Clearing House Association’s (NACHA) Council for Electronic Billing and Payment is a widely accepted set of business practices that define how EBPP transactions are to be conducted. The effort that went into creating the IFX for EBPP message set was based on strict adherence to the guidelines set in InteroperaBILL

InteroperaBILL is based upon the Service Provider model for EBPP. The Service Provider model is based on the concept that the process of delivering a bill from an originator ("the Biller") to the receiver (the "Customer") and processing the payment of the bill through the internet requires the participation of at least two entities but most likely will involve more than that since customers may access bill presentment and payment information through a variety of channels. IFX for EBPP focuses on making required information available to everyone involved in delivering the service.

The table below illustrates all of the entities/roles that can be involved in EBPP.

Term	Definition
Biller	Company or organization that sends a Bill or Statement, usually a request for payment for a product or service, to a customer.
Biller Payment Provider (BPP)	An agent of the Biller that originates and accepts payments on behalf of the Biller.
Biller Service Provider (BSP)	An agent of the Biller that provides an EBPP service for the Biller.
Customer	An individual or entity that receives goods or services which are the subject of bills or statements. The typical receiver of a bill.
Customer Payment Provider (CPP)	An agent of the Customer that originates payments on behalf of the Customer.
Customer Service Provider (CSP)	An agent of the Customer that provides an interface directly to customers, businesses or others for bill delivery. The CSP enrolls customers, enables bill delivery, and provides customer care, among other functions.

NOTE: the labels CSP, CPP, BSP and BPP are used to define a collection of functions and responsibilities. Any entity wishing to perform a particular role needs to address the issues and responsibilities defined for that role. It is also understood that one entity may perform more than one role, or that an entity may wish to outsource one or more functions of a role to others. For example, some Billers may serve as their own BSPs, some Financial Institutions may perform the role of both CSP and CPP, and some CSPs may outsource functions such as customer care to other service providers.

Comprehensive Definition of Data Elements and Data Relationships
IFX for EBPP was built based on these goals:

Capturing all of the data that is necessary to deliver the service while allowing room for customizations based on specific business needs.
Reliably delivering data across all of the entities involved in an EBPP environment.
Defining consistent semantic intent of tagged data elements and specific value domains for enumerated options.

IFX for EBPP was built by leading financial institutions, service providers and software vendors, working together to create a useful set of elements that encompass all of the data necessary to create EBPP networks. IFX for EBPP captures all of the fundamental data necessary to deliver an EBPP service as defined by InteroperaBILL while also allowing for customization within the strict IFX Framework.

End-to-End EBPP Functionality Coverage
The processing model on which InteroperaBILL is known as the "Thin Consolidation" model. In this model, the amount of billing and payment data that is sent is limited to supporting four core areas of functionality – Customer Enrollment/Service Activation, Bill Delivery, Payment Processing and Customer Care. This model, the operating rules developed by the NACHA bill payment council, and a sound architecture make IFX an extensible message specification, not just another XML DTD

Enrollment/Service Activation

Enrollment of customers with service providers.
Assignment of appropriate usernames and passwords.
Communication of disclosures for all involved parties.
Activation of bill delivery service between customers and multiple billers.
Registration and verification of customer payment methods.

Bill Summary Delivery

Delivery of bill summary data which includes biller information, account numbers, total amount due, due date and billing period information.
Inclusion of bill detail link to be passed through the service provider to the recipient. This bill detail allows for click-through functionality that allows for the customer to view line item detail data that is stored elsewhere and that is not communicated within IFX. Additionally, click-through functionality allows for single authentication of the user.

Payment Processing

Customer facing payment functionality through service providers
- Ability to schedule payments for bills received.
- Ability to schedule recurring payments (such as for a mortgage, car loan, etc.)
- Payment Status notification
- Customer initiated payments (pay anyone support)
Biller facing payment functionality
- Support for multiple payment methods.
- Support for multiple payment service providers.
- Support for round trip payment functionality including communication of remittance information.

Customer Care

Ability to provide status of bill presentment and payment to customers.
Updates to account information
Communication of new disclosures.
Facilitation of enrollment / de-enrollment in EBPP service.

Integrated with the rest of IFX
The IFX EBPP service is integrated into the IFX Framework – the foundation of the IFX Specification that includes a set of common objects that can be used across multiple types of financial services. This facilitates the implementation of cross service applications; particularly beneficial to corporations that offer a range of financial services other than EBPP.

For example, with a common definition for a "customer" that is used across multiple services, multiple types of applications can leverage off of one standard to utilize that piece of data. A financial institution that wishes to offer seemingly disparate services (such as banking and insurance) that may be located in different business units can take advantage of the common object definition to unify the disparate systems.

IFX for EBPP Features and Benefits

Enrollment and Service Enablement Functionality
Feature	Benefit
Complete customer enrollment features.	Account Setup Registration and verification of Customer Payment Methods Customer Payees Definition Assignment of usernames and passwords.
Ability to enable EBPP service to multiple billers.	Customer Authentication Service Enrollment with Multiple Billers Customer Disclosures Processing
Activation of customer EBPP accounts.	Navigation of Message Routing

Bill Presentment/Delivery Functionality
Feature	Benefit
Support for thin consolidation model	Delivery of bill summary information.
Error Processing	Ability to detect and re-process any errors incurred while delivering information.
Status reporting	Communication of a bill summary having been viewed by the customer back to the biller.

Payment Functionality
Feature	Benefit
Support for multiple payment methods.	Check, electronic, ACH, FedNet, SWIFT, CHIPS, CHAPS, BookEntry, Draft
Multiple payment functionality options	Support for multiple payment options Pay Anyone Roundtrip Payment Remittance Pay Some Scheduled Payments (Recurring and Single)
Payment Status Reporting	Ability to determine the status of any payment to all the interested parties.
Funds Availability Verification	Verification of customer payment methods.
Roundtrip payment support	Ability to process and communicate payment and remittance data.

Customer Care/Service Functionality
Feature	Benefit
Account maintenance functionality	Support for changes in account information such as account number and customer information.
Customer Service Enrollment/De-Enrollment	Ability for customer service reps to enroll and de-enroll in services on behalf of the customers.
Holiday Schedule Communication	Communication of service providers (such as financial institutions) service availability.

[ Top ]