Digital platform
A new digital banking platform.
The bill pay experience has to match it.
Bill pay conversion
Converting bill payto a new provider.
A bill pay conversion, on its own or as part of a wider digital conversion, moves your customers' payees, recurring payments and future-dated payments to a new provider while their bills keep coming due. Each scheduled payment has to be paid once, on time.
Why switch
Why institutions switch bill pay providers.
Cost
Pricing that fits how customers pay.
Per-transaction and per-active-user pricing reward different usage.
Performance and reliability
Payments that arrive on time.
A late payment costs your customer fees, and possibly credit standing.
Electronic delivery
More electronic payees.
Fewer paper checks, and faster delivery.
What converts
Most providers leverage six to eight conversion data files.
Conversion data is usually provided in your current vendor's format, and needs to be transformed to the new vendor's specification. The complexity on the institution's side is in reconciling and testing the new provider's platform configuration, rules, and data conversion.
- Customers, consumer and business
- Funding accounts
- Payees, with their addresses and account numbers
- Single payments, including every future-dated one
- Recurring payments and their models
- Business subusers and their rights
- Payment history, where it converts
The specification
Read it as a list of transformations.
Restricted special characters, field lengths, file layouts, delimiters and validations are each checked against your data and turned into a transformation rule before the first mock.
History
Decide how much comes across.
Payment history is the customer's record of what they paid. Often a year to eighteen months converts; plan where the rest is kept and how customers and staff will find it.
Transmission
Treat the files as the most sensitive data you hold.
Conversion files carry customers, accounts and payees together. Agree a secure, private transfer with the new provider before the first file moves.
Spend 30 minutes with us
Talk with us about your bill pay conversion.
No pitch, no obligation. And if we're not the right team for it, we'll tell you that too.
Recurring and future-dated payments
Scheduled payments are the ones that go wrong.
Customers set them up months ago and expect them to keep running. Each one has to stop on the old provider and start once on the new one.
Recurring payments
A recurring series converts as a payment model.
Each series carries a payee, an amount, a frequency, a next date and an end condition. Providers model them differently, so each one is translated, its next date recalculated, and the old provider stopped from generating it past the cut-off.
Where it slips
A frequency the new provider does not offer, a next date that moves by a day, or a series that both providers pay.
What we do
Translate every series, then reconcile it: same payee, same amount, same next date, generated by one provider only.
Future-dated payments
Everything scheduled past the cut-off changes hands.
The old provider terminates every future-dated payment past its last processing day, and the new one takes them from its first. Payments due over the cutover weekend, and the difference between a deliver-by date and a send-on date, decide when money leaves the customer's account.
Where it slips
A payment due on the Monday after cutover that neither provider sends, or a check already mailed that clears after the switch with nobody to answer for it.
What we do
A cut-off plan agreed with both providers, every scheduled payment reconciled across it, and inquiries on the old provider's payments routed back to the old provider.
Testing
Payments can't be tested end to end outside production.
Lower test environments aren't connected to the core's posting, the payment networks, check printing or settlement, so payment generation, execution and settlement run only in production. Everything around them can be proven first.
- 01Every mock, reconciledThe provider's exception reports, plus our own reconciliation of every customer, payee, series and scheduled payment against the source. A small conversion whose mock 2 runs fully clean inside the window can stop there; on a larger one, nothing in the conversion code changes between the final mock and the dress rehearsal.
- 02Files against the specificationDebit, posting and reporting files checked field by field against both providers' specifications and the core's formats.
- 03The old provider's stopStopping processing on the legacy platform can be tested before the weekend, and is.
- 04A controlled first runWhere the providers allow it, a small set of real payments by friendly users proves generation, execution and settlement before customers depend on it.
- 05The first processing day, watchedEvery payment due that day followed through the provider's monitoring site and the command center until it settles.
Funding models
Decide the funding model before you map.
The funding model decides when money leaves the customer's account and who carries the risk until it does. Changing it in a conversion changes what customers see, so it needs a decision, a customer notice and a support script.
Good funds
Secure the money first, then pay.
Funds move from the customer's account to a settlement account before the payment is sent. The lowest risk for the institution; customers see the money leave earlier.
Due date
Pay on time, collect on the due date.
The institution advances the payment and debits the customer on the date it is due. A smoother experience for customers, and higher financial risk, which is why many institutions avoid it.
- Payees moving from check to electronic delivery arrive sooner, which can change when funds are drawn.
- The new provider may not fund from savings accounts or credit cards that customers use today.
- Limits and funding rules that change are among the first things to tell customers about.
The cutover
The cutover runs from Friday to Monday.
Providers generally don't process payments on weekends, so the conversion fits between the old provider's last processing day and the new provider's first.
- FriThe cut-offThe old provider's last processing run; everything scheduled past it is terminated there, and the final files are extracted.
- SatConvert and validateFiles built, transmitted securely, loaded and reconciled. No payments are processed.
- SunReady to openExceptions resolved or accepted, the go/no-go signed, customer messages and support scripts live.
- MonThe first processing dayThe new provider's first run, every scheduled payment watched, the command center open.
- AfterThe first cyclesEach recurring series checked as it runs, questions about the old provider's payments routed back to it, until every customer's bills have come due once.
The providers
Bill pay conversions we've already mapped.
Many of the moves between the major bill pay providers are already mapped, with the field-level crosswalk from one provider's extract to the next provider's conversion files, the code translations and each one's edge cases.
FiservCheckFree bill paymentfiserv.com
FISBill payment, including the former Metavante platform
Jack HenryiPay and Payrailz bill payjackhenry.com
For a provider not listed here, the map is built and reconciled the same way, from both providers' specifications.