Bill Pay

What is Jack Henry’s iPay?

The bill payment application is a payment remittance tool in online banking used to pay bills to their respective vendors that range from lawn services, rent/mortgage or possibly the utilities for their home or workspace.  Some of these payments may have a recurrence established albeit weekly, monthly, or annually; depending on the payee/vendor’s relationship with the customer/company that is remitting the payment.

Why convert/switch providers?

• Tech Platform Upgrades: Banks are investing in modernization of the digital banking experience, in addition to the individual products and services (and experiences) available within the digital applications.
• Cost Efficiency: Vendors may charge per transaction or based on active users – understanding how your customers use this capability will inform the most cost-effective pricing model.
• Performance and Reliability: Stability, speed, and precision in processing payments are critical. Not all vendors scale equally, and late delivery of payments may result in fees and potentially impact to the customers credit rating.
• Enhanced Features: A higher number of established electronic payee relationship versus paper check delivery also increases customer satisfaction.

Shortcomings in these areas are some of the reasons financial institutions seek out a new partnership with a new vendor.

Key considerations during implementation kick-off…

• Processing Models (Good Funds/Due Date) – The good funds model moves the money from the client’s account to a settlement account to secure the funds before payment is remitted.  The Due Date model is used when the customers’ payments are paid in advance by the financial institution and payment is debited from the customer on the date that the payment is due.  This is a higher financial risk model that many institutions shy away from due to the risk. Which is right for your bank?
• Data Gathering & Identifying GAPs
  • • Consider the customer experience, including navigation, key functions & capabilities.
    • Perform gap analysis to ready the institution and its customers of the upcoming changes.
    • Evaluate the method of connectivity – This may range from a Dual Sign On method or a Single Sign On means of entry.
    • Consider the payee impact – Vendors that are presently being paid by check could be updated to an electronic delivery and shorten the time of delivery of that payment and affect when the funds are drawn for that payment.
    • Platform capabilities and limitations – The go forward application may not support funding on non-DDA (Direct Draft Account) type accounts, although customers may presently use Savings Accounts or Credit Cards.

Don’t underestimate data mapping…

The complexity of data mapping is typically on the bank side, sourcing the relevant data for conversion. As an example, Jack Henry’s iPay conversion process requires 6 to 7 files set Consumer/Business, Bank Accounts, Payees, Single Payment, Recurring Payments/Model, Sub-User and an optional History file.

Data feeds will need to be developed by the bank…

The file specifications provided by the vendor will serve as the map for the data conversion. The mapping process ensures that the data lands in the appropriate space during the conversion event.  The file specifications aid in the translation of data and understanding the language that the new vendor speaks.

There will be requirements withing the specifications that could include a restriction of certain special characters or possibly a character length in certain fields.  These limitations are called out in the specifications document and used to build the files to be ingested by the go forward vendor, and must be evaluated against the existing platform to identify all transformation requirements.

The specifications will also include details for file layout, such as file type, delimiter, and other relevant technical details and validations. 

Transmission of the conversion data must be done securely, as the conversion data is of the most sensitive nature. Establishing a secure private means to transmit the data is something that should be established with the go forward vendor.  This may include secure FTP, or a secure link with log-in credentials for file transmissions.

Be sure to consider historical data…

Bill payment history is often used as a point of reference of payments that have been remitted by the customer and that history may or may not be converted with the move.  If it is converted, there only may be a certain period that is converted.  This could be 1 year or up to 18 months, which is generally an industry standard.

Testing the new Bill Payment platform

Once the configuration requirements have been defined, data mapping and file delivery solution architecture has been agreed upon, you’ll be ready for testing and transition to the new platform.

• Test Environments – Most vendors, like Jack Henry/Fiserv etc. will provide access to a test environment that will be specific to the converting financial institution. This environment will afford the financial institution the ability to validate the converting data during mock conversion events prior to the production move.
• Test Scenarios, Cases, and Scripts – The banks IT QA team (or a strategic vendor partner) will identify the key functional and conversion related testing exercises that must be completed. Test scenarios, cases, and scripts can be used to ensure the platform and conversion process have been exercised thoroughly.
• Data Conversion Testing – Most vendors, like Jack Henry, will offer a set of exception reports once they complete a conversion effort.  The exception reports will direct the team to areas that could be finetuned prior to go-live.
• Payments Testing – Exercising payments in lower/test environments is typically a challenge for most implementations. Generally:
  • • You may not be able to effectively perform payments testing end to end because of the limitations of the core processors and payment rails not being available to the test regions.
    • You will be able to perform testing of your processes to discontinue payment processing on the legacy platform with the existing processor.
• Cut-Off & Transition Testing – The “cut-off time”,  or the last day and time that the financial institution will be processing payments on the existing platform is determined by the financial institution. That date/time  is generally the Friday before the go-live day on the go forward platform.

Like most vendors, Jack Henry does not process payments on weekends, and their first day of processing will be the next business day. A master site will be provided by the vendor, which allows the financial institution to confirm payments will go out as scheduled on production go-live. The site typically also be used to monitor user activity during and immediately following go-live.

Platform Go-Live Event

It is essential to understand when you will be terminating the legacy service, and when the new vendor will begin processing payments.  That generally is done during the Go-Live weekend.

• Platform Transition – A cut-off process should be established with the existing vendor to not only provide the files required to begin processing with the new vendor, but to also terminate all future dated payments past the agreed last scheduled date of their processing.  That date is normally on a Friday, with the go forward vendor beginning their processing that following Monday.
• Customer Communications – Generally the bank’s marketing/customer communications team organizes a series of communications to inform customers of the upcoming changes. The customer should be made aware of any planned payment cut-overs, failures and/or changes to scheduled payments. Planned limit adjustments/changes and funding rule changes (i.e. non-DDA funded transactions) are also typically important to communicate in advance.
• Bank Support/Command Centers – It’s also essential to plan the bank-side support model. Running a conversion command center is typically recommended as your first line of defense during and after go-live. Operated as virtual or in-person “war room” style support, having a dedicated team for escalations and platform/transaction monitoring will ensure the smoothest possible launch and customer satisfaction/issue resolution.