Prepaid Enterprise

Backstage is where all the action happens

I’ve been fortunate enough to participate in and contribute to the set-up of what I consider to be one of the most innovative prepaid TPP initiatives around. Although my forte is not implementation and operations, it’s always fun to see a large project coming together. We don’t realize how crazy things are behind the curtain because all we see is the final production. Over the last few months, I’ve been rubbing elbows with some extremely smart people as we move closer to launch. A great experience I plan to share via some blog posts. See you back stage!

 

Technorati Tags: prepaid issuing,project management,prepaid mastercard,prepaid visa,card management

Bad GPS…Bad GPS – part 2

In part 1 of this post I compared my comical experience with a rental car GPS system and what a prepaid card program manager experiences in the real world. In this post I’ve put together a a short list of report types and how inter-report relationships supply business intelligence to the enterprise. keep in mind different organizations may refer to these reports by different names or have several sub-reports but the concepts are pretty standard.

Report by Name, Description and Function

1. Account Creation
   • Daily, weekly, monthly report showing all newly generated PANs awaiting fulfillment and activation.
   • Basis for card sales report and fulfillment file creation process.
   • Can be used to audit sales reports and fulfillment vendor billing.
   • Used to reconcile TPP billing for new account creation (if applicable)
2. Account Activation
   • Daily, weekly, monthly report showing all newly activated accounts. Activation can be originated via IVR, Live agent, web, etc. Activation typically triggers the insertion of accounts into an authorization host in a “ready for use” state.
   • Critical relationship with Account Creation report. Tells the program manager if card sales are resulting in real conversion to a cardholder intending to use the card.
   • Account activation does not equate to an active, fee generating customer. It simply means the cardholder has “turned on” the account.
   • Used to measure effectiveness of packaging, marketing materials and distribution strategy.
3. Program Summary or Balance Summary
   • Daily report showing a summary of all transactions including network,  local and fee collection (fee or billing may also be a separate report or sub-report)
   • Represents current balance of physical funds at issuing bank.
   • May show breakdown of activity, aggregate balances and revenue by client and/or specific hierarchy entity.
   • Critical relationship with Account Creation and Account Activation Reports. Actual fee generation will tell the real story on the success of your card sales and distribution strategy. This report will expose how many real conversions are happening:
     • Card Sale = Account Creation
     • Intended Use = Account Activation
     • Real Conversion = Fee Collection (this concept will vary for retail distribution methods or other methods which require upfront payment prior to card issuance)
4. Negative Balance
   • Daily, weekly or monthly report showing summarized and detailed accounts with outstanding negative balances.
   • May show true negative balances due to posted transactions from the network and “receivables” created by uncollected fees separately (if they are not showed separately good luck with trying to reconcile!)
   • Critical relationship with Program Summary Report. Enables the program manager or issuer to manage losses, reserve account requirements and overall portfolio profitability.

The four primary report types listed above are in my mind the most critical and could be the basis for dozens of sub-reports. Reports are typically delivered in a flat file or raw format leaving the program manager or issuer to build tools to manage analytics. The good news is while attending the 2009 Prepaid Expo in Orlando last month, I sat in several general sessions where Third Party Processor representatives announced new business intelligence reporting capabilities. Looks like everyone’s trading in the old GPS.

 

Technorati Tags: prepaid debit,program management,prepaid issuing,payment systems,card management

BAI Retail Delivery Conference & Expo

Hugh Bursi and I attended the BAI Retail Delivery Conference & Expo in Orlando, FL. We sat in some really good sessions and some mind numbing ones. The highlight of the event was listening to Colin Powell and ING Direct CEO Arkadi Kuhlmann. Awesome approach to leadership and strategy. I left pumped. I also had a chance to spend some time with Hugh. We had some great conversations on how to grow the business and I will be learning a lot from him.

 

Be on the look out for my notes from the event. I'll compile my chicken scratch and post them over the next few days.

 

Technorati Tags: BAI Retail Delivery,Retail Banking

Hurry up and wait!

The other day I was driving through downtown Dallas and I could see in my rear view mirror, an SUV swerving between lanes in an attempt to pass everyone up including me. Eventually the hurried and obviously irritated driver made it past me. The interesting thing I noticed was that as the SUV sped up to pass, another car slowed down in order to block him from getting into the far right lane. A reaction of defiance and irritation. After all was said and done and two traffic lights later, guess who was sitting at the red light along side me! The Indy 500 SUV driver. All that fuss and no forward progress. The end result - two pissed off drivers and a great blog post topic.

As a program manager or MSP in the prepaid debit space, the above scenario is typical as you work through every aspect of the business. In order for us to develop, launch and manage a prepaid card program, we are required to rely on people and organizations that have the ability to hide behind words like Compliance, Regulation and Approval. It's not a deal breaking occurrence, unless you have the personality of a wet mop. When was the last time you were told by your issuing bank rep that the artwork for the new card design is still with MasterCard's Brand Standards department awaiting approval? If you submitted the artwork two weeks ago you may want to look inward to see how you managed to get to the bottom of your reps inbox. It is a possibility that you, like the SUV driver, were blocked by another driver in defiance of your bad attitude (perceived or real.)

There are some things you just can't push (like red lights) but you can improve your effectiveness by being courteous, sincere and knowing when and how hard to push for accountability. The goal here is to forge a solid relationship with your counterparts so that you can magically float to the top of the inboxes of your universe. Remember, technical knowledge isn't enough for topnotch project management. We're in a "Hurry up and wait" environment and you can cut unproductive time down by simply being a good driver.

 

Technorati Tags: prepaid debit,prepaid card,prepaid issuing,program management,business development,project management

To Process or Not To Process - Part 2 - Planning Phase

In Part 1 of this post I discussed some of the challenges program managers typically face when dealing with their processors. After going back and reading the post again, I think I may have been unfair to the hard working Third Party Processors out there. The purpose of the post was not to bash processors but to kick off a discussion on the options program managers have. At the end of the day, as the card business grows, a program manager is faced with a decision primarily revolving around natural progression. If the business executes well, it will outrun the processors ability to deliver acceptable results in terms of product development, delivery and support. The program manager worries about his business and a processor worries about 100 other businesses. What starts out as the ideal scenario on day 1 usually turns into a struggle to maintain momentum.

Does it make sense for every program manager to process their own transactions? Absolutely not. Implementing an issuing platform is a significant undertaking. The good news is no matter what anyone tells you, it is not overwhelmingly difficult. There is a clear and definite path to accomplish this and with the right team it could  even be a breeze.

So lets get down to nut cracking. Once the decision to become a processor is made a few high level questions need to be answered.

1. Will your current issuing bank support the initiative? I recently visited with one of the largest prepaid issuing banks in the country to assist a customer with bank coordination. It was clear the bank was not in support of the transition. Reason cited - "We've seen too many companies fail at this." Such a true statement. We've seen it too. What usually happens is the program manager will pick up a high priced platform and get locked up in implementation confusion. Part of getting your bank to buy in to the project is to build a strong case showing you not only have an executable plan, but a proven platform and an experienced team to back you.
2. What issuing/authorization platform should you consider using? Think real hard on this one. It will to be the heart and soul of your business. Does the platform you're considering support the intricacies of prepaid issuance? Is it PABP certified? (My OLS colleague David Bergert has some great posts covering PABP on his blog) What type of support does the platform come with? Does the software vendor charge extra fees for Capacity Events? Can the platform run on commodity hardware? Be sure to consider OLS.Switch in your review process. My OLS Colleague Andy Orrock covers the Buy vs. Build topic on his blog.
3. Do you have the necessary in-house expertise to manage a payment switch? If you don't, hire someone our outsource this function to an experienced firm.
4. Will you use a gateway processor to connect to the world or will you house the MIP/VAP in-house? I personally think having an endpoint in-house brings no extra value unless you plan to branch out and provide gateway processing services to other organizations . In fact, it will increase your fixed cost, compliance responsibilities and liability. Remember the word "liability" will make your issuing bank cringe. Contract with a gateway processor for a inbound authorizations at a few cents a transactions. You'll be glad you did.
5. Will you perform a full BIN conversion or implement a soft transition strategy? I've been involved in two BIN conversion projects. I would wish this experience on no one. I don't think there is a processor out there that would make the conversion process a peaceful event for a program manager. After all, why would they make it easy for the competition? Notifying cardholders, printing new materials and the process of transferring account balances and pending authorizations is critical. If the ball is dropped you will lose cardholders. If the transition goes well, you'll lose less. Attrition due to change is unavoidable. In most cases, a soft transition is advisable. Simply stop issuing new cards on the old platform once you are ready to go live with your new system. Your portfolio will naturally transition over.
6. What third party services will you need to integrate with?
   • Gateway processor
   • Card personalization and fulfillment
   • OFAC/CIP
   • IVR Systems
   • Live Agent Support (if you choose to outsource)
   • BiIlpay
   • Money Transfer
   • Other

Please keep in mind the questions listed above are from a 50,000 foot view. More questions will arise throughout each planning stage as you move towards implementation.

More questions and answers to follow in Part 2.1.

Peace.