MR3.9.0 RELEASE OVERVIEW July 2012
MR3.9.0 Overview Agenda ATM/Debit Star Network Master Card Mandate PIN vs. Signature Fee Options MagTek Instant Issue Member Service Lending Exclude Shared Branching Fees Based on Access Medium Exempt Accounts from Dormancy Fee based on Balance Fed Holiday Option for Check Holds Support Alpha Characters for Mortgage Loan Note Number Monthly Renewable Credit Insurance Skip Payment Disclosure Calculation Oracle Discoverer New Fields Added for Direct Deposit, Product Classes, Skip Months and Removed Loan Draft Type Back Office General Ledger Error Corrections
ATM/Debit Star Network Master Card Mandate PIN vs. Signature Fee Options MagTek Instant Issue
STAR Network Mandate Effective July 31, 2012, STAR require issuers to support enhancements in the areas of transaction security, alternative authentication methods, as well as new and modified payment transactions for Face-to- Face and Non-Face-to-Face transactions. Network Enhancements to CO-OP Adapter Changes to the CO-OP adapter (coopiso) were completed to support the Star Network Enhancements providing the ability to support the new processing code 54xx00.
Master Card Mandate Business Case MasterCard is requiring issuers to support the use of trace data for incremental pre-authorizations. Note: Acquirers are not required to comply with this requirement until Fall 2012, however, they can continue to submit incremental authorizations, including trace data, after April. Host Modifications To support the MasterCard mandate, the following host changes were completed to support the use of trace data for incremental pre-authorizations: 1. A new column was added (TN_TRANS_DS) to allow storage of the trace data. 2. ATMMPI was modified to use incremental trace ID when processing incremental preauthorizations. 3. Progeni schema (stripe.spc) was modified to add TN_INCREMENTAL_TRACE_ID to TN_TRAN_DS Adapter Modifications To support the MasterCard mandate, adapter changes were completed to pass the trace ID to the host system. Report Enhancements To support the MasterCard mandate, ATMHST was modified to print the incremental trace ID.
PIN vs. Signature Business Case Prior to this release, i-power did not provide the ability to distinguish between Signature vs. PIN transactions for the purposes of feeing. It is a fact that credit unions receive higher interchange from Signature based transactions and must pay the merchant for POS PIN based transactions. With MR3.9.0 credit unions now have the ability to charge the member for POS transactions based on a count. For example, the credit union could set up a fee plan that would allow free Signature Based Transactions and fee for POS PIN based transactions. By providing the ability to fee against transactions and distinguish between POS and Signature based transactions the credit union will have the ability to encourage members to use Signature (swipe card and select credit) as opposed to POS (swipe card and enter PIN).
PIN vs. Signature Implementation Considerations Credit Union must be using the i-power Fee Plans with the following condition set: PIN/SIG Fee Plan Indicator If the credit union chooses this option then if the existing fee plan(s) had any exclusions associated with POS under any of the transaction groups, i-power will populate the same exclusions under both the Signature Point of Sale Transactions and PIN based Point of Sale Transactions transaction groups accordingly. If the existing fee plan(s) did not have any exclusion(s) associated with POS under any of the transaction groups, i-power will not make any changes to the fee plan(s) to accommodate the new transactions groups.
PIN vs. Signature PIN/SIG Fee Plan Indicator
PIN vs. Signature When the PIN/SIG Fee Plan Indicator is conditioned to Use PIN/SIG Feeing, i- POWER will adjust the existing fee plan(s) to accommodate the PIN and Signature transactions groups as follows: 1. Does the credit union use the fee plan structure located within i-power? a. If yes, proceed to next step. If no, no adjustments are required. 2. Does the credit union have any exclusions that contain POS under any transaction groups? a. If yes, proceed to next step. If no, no adjustments are required. 3. Under the Signature Point of Sale Transaction groups, select the appropriate checkbox(es) for any exclusions that contain the same exclusion and processing code (6 digit number in parenthesis next to exclusion) as the POS exclusion(s) selected within the transaction groups (i.e. Withdrawal, Deposit,Transfer, Payment).
PIN vs. Signature 4. Under the PIN-based Point of Sale Transaction groups, select the appropriate checkbox(es) for any exclusions that contain the same exclusion and processing code (6 digit number in parenthesis next to exclusion) as the POS exclusion(s) selected within the transaction groups (i.e. Withdrawal, Deposit, Transfer, Payment). See example below. Note: i-power will populate all POS exclusions under both Signature Point of Sale Transactions and PIN-based Point of Sale Transactions groups in order to convert to the new fee plan structure (PIN vs. Signature). The credit union will need to confirm adjustments for all fee plans to ensure they want to keep their existing fee plan structure in correlation with the PIN and Signature transaction groups.
Example In this example, it shows that the POS exclusions under the Withdrawal transaction group are populated under the Signature Point of Sale transaction group. This will ensure that the POS transaction exclusion(s) are the same under the Signature Point of Sale Transactions group and Withdrawal to accommodate the PIN/SIG Feeing method (ability to differentiate and fee against PIN and Signature transactions).
MagTek Integration i-power - MagTek Integration - Phase II With the i-power MR3.8.0 release, a batch process was developed with MagTek s QwickCards application to support instant issue cards. With the MR3.9.0 release, a web service was implemented between i-power and QwickCards via to automate the instant issue process (alleviating the previous batch process where files were transmitted each night). With this enhancement it will allow the credit union to create the card record within i- POWER and print the card using the MagTek hardware (QwickCards, EC1000 or EC500, ipad and/or Intelicoder) while the MagTek device updates i-power accordingly (i.e. PIN Offset). There are 2 main components associated with Phase II: Setup Real Time Messaging with the Network a. Communication from i-power to Network <CO-OP> b. Communication from MagTek to Network <Vantiv> Note: EPL, Inc. is working with CO-OP FIS and Vantiv to setup Real Time Messaging for Instant Issue cards. Additional feature requests and certification will be required to setup Real Time Messaging with other Networks.
Member Services Exclude Shared Branching Fees Based on Access Medium Expand Dollar Amount Exemption for Dormancy Fee based on Balance Fed Holiday Option for Check Holds
Exclude Shared Branching Fees Based on Access Medium Prior to this release, credit unions did not have the ability to exclude shared branching fees if the transaction was originated from a mobile phone, call center or online banking channel. With this release, EPL now has the ability to include/exclude shared branching fees based on the medium: Exclude/Include Shared Branching Fees originating from a Mobile Phone Exclude/Include Shared Branching Fees originating from a Call Center Exclude/Include Shared Branching Fees originating from Online Banking Installation & Setup Please contact EPL ODI EFT Support at 1-877-581-8338, Option 1 to have this capability setup and installed for your credit union. There will be a one-time charge associated for installation, testing and setup.
Expand Dollar Amount Exemption for Dormancy Fee Based on Balance Prior to this release, credit unions were only able to exempt members from a Dormancy Fee based on a balance greater than 999.99. With MR3.9.0 credit unions now have option to exempt accounts with balances up to 9,999,999.00 from Dormancy Fees.
Fed Holiday Option for Check Holds Prior to this release, not all federal holidays were counted as non-business days. With MR3.9.0, credit unions now have the ability to count all federal holidays as non-business days when placing check holds on i-power transactions. Currently the system only counts federal holidays defined in the data center holidays as business days (for example Columbus Day is a data center business day, but a federal holiday). The system can now recognize all federal holidays and exclude them from check hold days when placing check holds on i-power transactions. EPL Data Center customers should contact EPL ODI Deposits Support at 1-877-581-8338, Option 2 in order to activate this setting. In-house customers should refer to the implementation instructions in the System Update or contact their IT Department.
Lending Support Alpha Characters for Mortgage Loan Note Number Monthly Renewable Credit Insurance Skip Payment Disclosure Calculation
Allow entry of Alpha Values and Special Characters in Note Number for Mortgage Loans With MR3.9.0, the Note Number field on the Mortgage Loan only allowed for entry of numbers. With this release, the system now allows entry of alpha and special characters in the Mortgage Loan Note Number field. i-power Screen Change(s) Other than accepting entry of the alpha and special characters, there are no screen changes for the user.
Monthly Renewable Credit Insurance Prior to MR3.9.0, the system only considered the Level Rate plans for Credit Disability (LRCD). With MR3.9.0, modifications were implemented to consider the rate file for an active Monthly Renewable Credit Disability (MRCD) plan, if an active LRCD plan is not found. The information in the plan, including the premium type, rates, and maximums, are submitted to the calculation engine, which returns the proper front-end disclosures. The system utilizes the same insurance code structure for MRCD as it does for Level Rate Credit Insurance; it is the plan that indicates whether the Credit Disability is Level Rate or Monthly Renewable. Therefore, no changes to the screens were necessary for this part of the feature. When booking a new loan or add-on, the system will update the loan record with the insurance code, as follows: 0 = No Insurance 1 = Single Credit Life 2 = Disability 3 = Single Credit Life and Disability 4 = Joint Credit Life 5 = Joint Credit Life and Disability
Dual Plans for Home Equity For credit unions offering dual plans for regular vs. home-equity loans, there now will be a second set of insurance plans in the rate file that will indicate there is a dual contract for Home Equity. This allows the credit union to offer different rates, age limits, and maximums, for their home equity loans versus their regular loans. Modifications were made to use the rate file for an active Dual Contract plan for Home Equity for Credit Life and Credit Disability and, if found, the system will display additional insurance options with Equity in the description. It is up to the user to determine if the loan qualifies as a home equity and select the proper coverage. The information in the plan, including the premium type, rates, and maximums, are submitted to the calculation engine, which returns the proper front-end disclosures.
Dual Rate Plans - continued The Insurance Codes coverage type saved back to the loan record upon booking are as follows: 0 = No Insurance 1 = Single Credit Life 2 = Disability 3 = Single Credit Life and Disability 4 = Joint Credit Life 5 = Joint Credit Life and Disability 6 = Single Premium 7 = Equity Single Credit Life 8 = Equity Disability 9 = Equity Single Credit Life and Disability 10 = Equity Joint Credit Life 11 = Equity Joint Credit Life and Disability Note: For Home Equity Dual Plans, setup insurance codes 7-11 and description under System Codes prior to booking loan application with Equity Insurance Options. If offering Dual Plans for Home Equity, please work with EPL ODI Lending Customer Support for setting up monthly premium processing utilizing CMG s Payment Protection Calculation Service (PPCS).
i-power Screen Changes
System Code Set Up for Dual Plans When offering Dual Plans for Home Equity, the user must set up the Equity insurance codes and descriptions under Manage Insurance Codes. Navigate to Manager\Institution\Consumer Loans\System Codes\Insurance Codes.
Skip Payment Disclosure Calculation With MR3.9.0, modifications were made to LOS to request a disclosure calculation from the CUNA calculator to accommodate a consecutive skip month period and save back the desired skip months under General Loan Info.
Step 1 - Select Payment Skip Months Option
Step 2 Select Months to Skip In this example the loan is 36 months with skipping July and August Payments
Calculation Results The system calculated 30 payments, skipping 6 payments of July and August every year.
Oracle Discoverer New Fields Added for Direct Deposit, Product Classes, Skip Months and Removed Loan Draft Type
Oracle Discoverer New Fields Added Direct Deposit Indicator and ATM/Debit Card Count - (Account Master) Customers purchasing the Deep Target reports for home banking are required to upload a file created from Oracle Discoverer. There was a need to be able to identify which members have an active ATM/Debit Card and which members are currently receiving Direct Deposit. Oracle Discoverer was enhanced to provide this data. For Direct Deposit a calculated field was added to count the number ACH Credit transactions for the member within that member s transactions within the past 45 days from the live database or for the month for month-end databases. If any are found, the indicator will be set to a 1 for Direct Deposit.
Additional Oracle Discoverer Field Updates Added Product Class to the All Products Folder Added Driver s License Description Added Skip Months Removed Loan Draft Type from Loan Product Class Loan Draft Type returns 0 no matter if the class is Home Equity or Signature, so this field may have been valid at one time, but no longer appears to be utilized or updated. The Loan Draft Type is determined by the class range. If 500-599, then it is a Home Equity and if 600-699 it is Signature. Since this field is currently displaying incorrect data, we have removed it from Oracle Discoverer.
Back Office General Ledger Error Corrections
General Ledger Error Corrections Prior to this release, transactions keyed in the same journal entry did not always contain the same transaction numbers due to other qualifiers and parameters. With this feature, a continuing receipt number (i.e. Memo Number) was added to support transaction sub-batches. As a result, a transaction batch, regardless of size or how many sub-batches are involved, will always have the same receipt number for all transactions included within the batch. Therefore, if the credit union chooses to error correct the transactions, it will Error Condition all transactions within the batch due to all transactions having the same receipt number.
Sample GL Posting Batch
Sample Error Correction of Batch
Questions