Opsol OmniPayments and HP NonStop systemsPowering the next-generation of payment systems

OPEN SOLUTIONS ARCHITECTS

oops L

OPSOL SOLUTIONS

Table of contentsExecutive summary………...................................... 2Solution overview ................................................. 3HP and Opsol advantage ...................................... 3OmniPayments solution ......................................... 4Optional OmniPayments functions .......................... 8HP NonStop systems ............................................ 11Appendix A – Foreign currency ............................12Appendix B – Charges/fee handling .....................13Appendix C – Transaction log ...............................14Appendix D – Post-dated transactions .....................15

2

Executive summaryIntroduction Many financial institutions face the need to update the services they offer through payment systems. Transaction rates from tellers, automated teller machines (ATMs), point of sale (POS) devices and from across the Internet combine to increase demands on the quality of service, as well as the number of services provided through customer touch points. At the same time, financial institutions need to respond to these trends while reducing costs and providing ultra-reliable service to retailers and customers.

Opsol OmniPayments running exclusively on HP NonStop systems is a proven solution that can provide answers to these problems and support up to thousands of devices and transactions from all potential customer touch points. The solution drives modern web ATMs that can easily provide access to new service offerings at the ATM or other customer-facing channels. For example, an alternate offering could be personal insurance that has been tailored for a specific individual.

Using innovative and enhanced payment capabilities, this Opsol and HP solution helps drive customer satisfaction by delivering outstanding levels of availability and scalability. In addition, improved system reliability helps reduce payment infrastructure costs, which can significantly increase the profitability of handling any number of ATM, POS and Internet-sourced transactions.

Combined with cross-channel and targeted services provided by the optional OmniHub product, OmniPayments running on HP NonStop systems can boost profit margins and competitive leadership even further.

Solution benefits•SupportswebATMandstandardATM/POSdevices

•Allowsforcustomizationofservicesdeliveredviaweb ATMs

•Providesacomprehensivesetofpaymentservicesand optional system of record (SOR) stand-in

•Deliversoneofthebestservicelevelsintheindustry

•Leveragesaprovenoperationalsystemthatsupportsover 8000 ATMs

•Supportsoptionalintegrationwithlegacysystemsto deliver a single customer view over multiple channels, improved fraud detection/prevention, and other advanced features

3

OmniPayments

ATM POS Switch

Solution overviewOmniPayments and HP NonStop systems provide a comprehensive solution for financial institutions to acquire,authenticate,route,switchandauthorizetransactions across multiple input channels such as ATM, POS, kiosks and the Internet. Based on a modern service-oriented architecture (SOA), the OmniPayments and HP NonStop solution consists of several service components,calledbusinesslogicmodules(BLMs),which interact to satisfy business needs in the retail banking payment environment.

Powered by industry-leading HP NonStop systems, OmniPayments allows the transaction originator (acquirer) to initiate a payment, request and receive authorizationforanactiononacustomercardoranaccountfromatransactionauthorizer(issuer).The transaction is then routed between the originator andtheauthorizer.TheHPandOpsolsolutioncanhandle both on-us and outside transactions. For transactions that must be routed to external issuers, the solution provides switch interfaces. And if the issuer is unavailable for any reason, the solution also provides optional stand-in functionality. In addition, OmniPayments and HP NonStop systems can manage all device and host application interfaces, as well as provide a comprehensive security framework. The solution can also interface to other third-party products or legacy systems, if necessary.

Since the mid-1990's, HP and Opsol have been working together to provide payment, enterprise messaging, single customer view and security solutions for financial institutionsofallsizes.Bycombiningstandards-basedNonStop infrastructure technologies with leading-edge Omni applications, HP and Opsol offer financial institutions powerful, flexible payments solutions that can resolve tough business challenges today—and dynamically adapt as those needs change.

HP and Opsol advantageProviding best-practice consulting and implementation services, you can work with HP and Opsol at every stage of your payments project—from initial project scope, to architecture and design, to solution deployment, to on-going support. With extensive experience delivering OmniPayments and HP NonStop solutions worldwide, you can trust the service professionals at HP and Opsol to deliver the right solution, at the right time, at the right price.

4

The OmniPayments solutionOverviewThe Opsol OmniPayments solution is an open, SOA, standards-based architecture that delivers reliable and scalable capabilities for today’s payments industry. The structureddesignallowsfortheadditionofSOABLMsthat can support new features and business functions as the market demands. OmniPayments provides a comprehensive solution for banks and other payment service providers to acquire, authenticate, route, switch andauthorizefinancialtransactionsacrossmultipleinputand back-end channels with value-added services.

OmniPayments allows the transaction originator to initiate a payment, make a request, and receive the authorizationforanactiononacustomercardoranaccountfromatransactionauthorizer.OmniPaymentsroutes the transaction between the transaction originator andthetransactionauthorizer.Itcanhandlebothon-usand outside transactions.

Payment platforms

OmniPayments

Legacy ATM

Web ATM

Back-endsystem ofrecord(HOST)

Payment networkse.g. VISA, Mastercard,AMEX, NETS

POStransactionsOmniPayments/POS

architecture diagram

For transactions that must be routed to external issuers, OmniPayments provides switch interfaces and optional stand-in functionality when the issuer is unavailable (see page 8 for an overview of stand-in functionality).

ThewebATMfunctionalityenablescustomizationoftheATM screen on a per-customer basis. Each customer can define default screens and preferred cash transaction values. Since many customers prefer speed over function attheATM,customizationcanimprovecustomersatisfaction, as well as increase server, network and ATMutilization.

Customizationcapabilityalsoenablesaninstitutiontomake timely modifications to its marketing messages for the general audience, as well as present targeted offers to individual customers.

The following display screen is an example of the OmniPayments screen.

5

Infrastructure management and securityOmniPayments monitors transaction capture devices on server and relevant host applications. Optional dashboards such as OmniDash can report real-time status of both business parameters (e.g., transaction per branch) and critical business functions (e.g., response times at POS devices).

In the event of ATM failure, OmniPayments reports the event, and then routes the error to the management server that handles that particular brand of device. Using the OmniPayments monitor function, OmniPayments interfaces with management servers to automatically manage the status of those devices. Once an error has been resolved, the device is returned to the desired state, such as online or test.

Along with OmniPayments, the optional OmniCrypto security framework can ensure the security of data at rest, as well as data on wire. Data encryption can be provided by hardware security modules from HP Atalla and other third-party providers. A software encryption option is also available.

OmniPayments ensures the proper recovery of devices, databases and applications from failures using alternate routing to providers, as well as automatic failover capabilities for hardware, software and networks. In addition, OmniPayments is designed to operate in a disaster-tolerant configuration (see page 9) with multiple ATM connections across clustered and geographically dispersed servers, if desired.

Interchange/switch interfacesThe OmniPayments switch interface can integrate with industry-standard interchange switches. Integration testing with these switches must be customer specific. To ensure a smooth process, Opsol offers comprehensive customer support during these testing cycles. For customer-specific compliance requirements, Opsol will update OmniPayments as necessary, typically rolling modifications into the standard product code base.

The OmniPayments switch interface supports the following industry-standard interchange switches:

•VISA,MasterCard,AMEX,NETS/eNETS

•PLUS,STAR,INTERLINK

The OmniPayments switch interface can support external networks conforming to either the ANSI or ISO8583 standard. Other switch networks can be added at low cost; typically, additional switches would then be supported as part of the standard code base. The OmniPayments switch interface translates the messages between its internal components and external networks; it can act as either an acquirer or issuer to the external network.

Payment platforms

OmniPayments

OmniDash

OmniPaymentsconsole

Web ATM

Back-endsystem ofrecord(HOST)

Payment networkse.g. VISA, Mastercard,AMEX, NETS

POStransactions

OmniCrypto

6

OmniPayments

Tx Acquisition

Tx Logger Payment switch Auth Data

Tx AuthenticationTx Router

Legacy ATM

Web ATM

HOST

Payment networkse.g. VISA, Mastercard,AMEX, NETS

POStransactions

"On-us" transactionsIn “on-us” transactions, the acquiring device and the account holder belong to the issuing bank. "Off-us" transactions are treated fundamentally the same way, but they originate (as far as OmniPayments is concerned) from a third-party switch. "Off-us" transactions may result in different fees or service treatments. These fees and/or treatments are assigned by the bank that defines transaction types in the logging module and assigns the appropriate action for each transaction type (see appendices for more detail on transaction type treatment).

ATM transaction setThe OmniPayments solution supports all standard and many advanced ATM transactions (see the complete list in the sidebar). When a transaction is initiated from an ATM, it is acquired and passed to the router module. The basic OmniPayments product is designed to support web-based ATMs, but can be enhanced to support optional interfaces such as TCP/IP or SNA.

After receiving a transaction, the router module decides which business logic module should handle the request. Depending on the transaction type, it will either be

directly executed within the OmniPayments application or passed to a peer service for additional processing before being returned to OmniPayments for capture of authentication data and logging.

For example, during a typical cash withdrawal, the router passes the request to the OmniPayments authentication module, which authenticates the transaction according to the system parameters (e.g., PIN or card status). The transaction is then transmitted tothehostforauthorizationprocessing.Whenthehostresponds, the transaction details are stored in AuthData, and then passed back to the router and transferred to the ATM channel for completion (see figure above).

If the host does not respond, the transaction fails and the appropriate message is returned to the ATM. If the optional stand-in function is installed, the router invokes thestand-inBLM,whichtypicallyprovidesnegativeauthorizationandlogsthetransactionforlaterhostupdate. The customer receives his cash (see page 11 for more details on the stand-in processing function).

Standard ATM transaction types supported:•Withdrawal

Fast cash withdrawal – preset account and value

Withdrawals with account and value selection

•Balanceinquiry•Cashdeposit•Creditcardpayment•IDapplication•Statementrequest•Mini-statement•Mobilephonestop-up

payments

Advanced ATM transaction types supported:•PINchange•Customizablefastcash

withdrawal Customer defines fast cash amount and account

•Invoicepayments•Balanceinquiry•Account-to-accounttransfer

orders •Advertisementandmarketing

actions at ATMs •Cardexpirationwarning•Retainedcardwarning•Mobileoperatorsbilling

7

Standard POS transaction types supported:•POSpurchase•Balanceinquiry•Pre-authorizations•Cashback•Checktransactions•Cashadvances

Advanced POS transaction types supported:•Cashcardtop-up•Cashcardrefund•Merchandisereturns•Purchaseadjustments

IVR transaction types supported:•Balanceinquiry•Fundtransfer/third-partyfund

transfer•Billpayment•Checkstatusinquiry•Stopcheckpayment•Ordercheckbookonline•Fixeddepositplacements•Fixeddepositwithdrawals•ATMPINreplacements•ATMcardactivation•IBPINreplacements•IBserviceactivation•Updatemobilenumberfor

SMS•Creditcardbalanceinquiry•Creditcardstatementinquiry•Creditcardtemporaryincrease•Creditcardrequestfor

statement

Branch teller transaction types supported:•Accountinquiry•Cashdeposit/bulkcash

deposit•Cashwithdrawal•Fundtransfer•Checkdeposit•Purchasecashierorder•Purchasedemanddraft•Telegraphictransfer•Billpayment•Forexsaleandpurchase•Timedeposit–placement

POS transactionsOmniPayments supports the standard and advanced POS transactions listed below. Processing POS transactions is fundamentally the same as processing ATM transactions. As logging occurs, the appropriate transaction details are stored to reflect the transaction source and other pertinent information.

IVR transactionsOmniPayments supports standard and advanced interactivevoiceresponse(IVR)transactions(listedbelow).IVRmessagescanbereceivedoverTCP/IPorSNA,CORBA,SOAP/XML,WebSphereMQandPathwayinterfaces.HandlingtheseIVRtransactionsisfundamentally the same from a logical view point as transactions sourced from an ATM or POS.

To ensure accurate account charges for services rendered, all transaction information must be logged. This step enables companies to gain critical business intelligence from historic data.

Branch teller transactionsMost teller transactions are delivered over TCP/IP or SNA, or from browser-based tellers. OmniPayments supports all these methods. Again, transactions from these devices flow through the OmniPayments application in the same manner as from other sources (see the list below for all supported teller transaction types).

This commonality of function is provided by the OmniPayments SOA architecture.

SOA designTransactionprocessingiscompletedusingSOABLMs.Infact,OmniPaymentsusesBLMstocompleteallbusinessfunctionsasasetofservices.ABLMmayalsouseservices provided by peer systems within the institution (see figure above).

A transaction is processed after OmniPayments checks the limits against the bank parameters, such as user profile and transaction code. Every processed transaction looks for the charges against the stored transaction rates. The charging module applies all rules on the rate, depending on transaction code.

The OmniPayments console provides an easy and user-friendly approach to add new transaction types or to update existing transaction rules. Setting up a new transaction code is a simple administrator function, completed through a browser interface.

EachBLMisresponsibleforcommunicatingwiththeloggingfunction.Usingtheconsole,eachBLMisconfigured to ensure it sends the desired macro data to the logging function.

Transaction loggingIn every situation, OmniPayments employs four-point transaction logging to ensure recovery and failure analysis, if required:

•Incomingcopy

•Outgoingcopytopeersystem

•Incomingcopyfrompeersystems

•Outgoingcopytorequestingchannel

In addition, other transaction details can be logged forlateranalysis.EachBLMcanbeconfiguredtolog transactional elements. The information logged can include data from any part of the transaction, such as customer ID or unique identifier; information about the user session; transaction start time and end time; originating channel name; originating source ID and description, transaction description and status (successful/failed); descriptions, customer account information and more. Reversal transactions are also logged in the system (see Appendix C for more details on the logging function).

OmniPayments router

Host adapter

OmniPaymentsconsole

Web ATM

Core banking

HP NeoView

Business intelligence

TCP/IP

TCP/IP

OmniPayments services• Acquisition• Authentication• Logging• Payment switch

• Single customer view• Offers• Encryption• Customer contact

ODS

DM DB

8

Optional OmniPayments functionsStand-in processingAs discussed above, online banking takes many forms—the most common being cash delivery through ATMs and POS-originating transactions. And because customers now expect 24x7 availability of online banking, lack of these services can negatively impact customer loyalty.

To ensure customer satisfaction, OmniPayments provides an easy-to-install option to stand in for ATM and POS payments. Please note that these features can also be extended to provide similar stand-in functions for many other services.

The monitor within OmniPayments tracks the availability of chosen services and informs OmniPayments when a service is down. A typical service that requires stand-in functionsisauthorization;butOmniPaymentscanbeenhanced to support stand-in functionality for other business-critical functions, when necessary. In this case, the stand-in strategy would be defined, and then the required data and logic would be stored on the OmniPayments platform and integrated with the monitor and routing functions.

If the host or system of record is unavailable, the stand-in mode is activated (see figure above). In this mode, stand-in system parameters are used and the transaction is processed locally on the OmniPayments server.

During stand-in mode, transactions are verified against thatfileandauthorizedaccordingly.Transactionsareplacedintothestand-inqueue(SIS-Q),andthenpostedfrom the queue back to the host on its return. The stand-in function continues until the host server is up to date, at which point original processing routing resumes.

OmniPayments Host Status Monitor

SIS-Q

AdaptersAuth

ATMIVRInternet

TCP/IP

Tuxedo,CobraMQ

FTP

ISO8583

Channels Hosts

ODS

Stand-in processing when host is unavailable

9

Optional dashboard functionsManaging the ATM and POS networks can be enhanced by using optional dashboard functions. These functions allow the user to define which elements of the system— such as ATM performance and business-level functions—to monitor in a dashboard-like fashion.

Disaster recovery Standard, out-of-the-box OmniPayments runs in a fault-tolerant environment. All critical components are duplicated in standard form, processors, discs, software components and network connections. All components are designed to withstand any single component failure and maintain the targeted service levels without loss of data, data integrity or transactions. However, critical payment services normally require consideration for catastrophic failure of the installation site due to power outages or major disasters covering large geographic areas.

OmniPayments is readily configurable to handle disasters, with many options that cover:

•Singlesite–dualservers

•Multi-site–dualservers

•Multi-sitedualserverswithlock-steptransactionprocessing ensuring no transaction is lost

•Multi-sitewithmultipleservers

•Multi-serverconfigurationcanbeactive/activeoractive/standby

Each of these options has different cost implications (network bandwidth, hardware costs, software throughput) that need to be considered against business risk. Regardless of the option, OmniPayments has a proven track record of handling the most stringent availability requirements.

Credit card transactionsHandling credit card transactions is a logical option that can be added to the core OmniPayments functions. In addition to leveraging the infrastructure of the ultra-reliable environment, the credit card option provides a single view of the customer across channels and banking products and services.

Once the option is installed, transactions from credit card switches enter the OmniPayments solution in a similar manner as from other channels. TCP/IP and SNA connections are supported, and once the acquiring process has passed the transaction into the product core, the usual process is applied to complete the payment.

Stand-in functionality can be applied to credit card payment processing.

Standard credit card transactions supported:•Purchaseauthorization•Merchantreversal•Adjustmenttransaction•Cashadvance

Common transactions supported as BLMs:•Accountinquiry•Balanceinquiry•Accountstatementinquiry•Accounttransactioninquiry•Blockstatusinquiry•Blockstatusmodification•Billpayeeadd•Billpayeedelete•Billpayeeinquiry•Billpayeeconfirmation•Cashdeposit•Onlinepurchase•POSpurchase•Creditcardcashwithdrawal•Debitcardwithdrawal•Cardtocardtransfer•ATMcashwithdrawal•Creditcardbillpayment•Creditcarddeposit•Creditcardaccountstatement

inquiry•Creditcardaccount

transaction inquiry•Customeradd•Customerinquiry•Customerpayeeadd•Customerpayeedelete•Customerpayeeinquiry•Customertransferdelete•Customertransferinquiry•Passbookupdate•Checkbookrequest•Checkstatusinquiry•Tokenrequest•Departmentaccountstatement

inquiry•Statementtypemodification•Loanaccounttransaction

inquiry•Paymentadd•Paymentcancel•Paymentinquiry•Paymentmodification•Recurringpaymentadd•Recurringpaymentcancel•Recurringpaymentinquiry•Recurringpayment

modification•Rewardaccountstatement

inquiry•Transferadd•Transferdelete•Transfermodification•Transferinquiry•Claimaccountinquiry•ChangePIN•Cashcardrefund•ApplicationforID•Applicationforservice

activation•Stopcheckpayment

10

Channel integrationA major advantage of the OmniPayments solution is that it can be integrated with Opsol OmniHub. Comprised of packaged software components, a flexible architecture and complete services, OmniHub supports an adaptive infrastructure and enables financial institutions to enhance payments and finance-related data with real-time, comprehensive, cross-channel information. OmniHub can integrate various channels—includingATM,POS,teller,IVRandInternetbankingchannels—and combine analysis of channel data with customer usage information to deliver targeted services and offers.

Using OmniPayments’ SOA infrastructure, services can be provided to peer systems and customer channels. The infrastructure also enables migration to new technologies by supporting legacy interfaces—delivering existing services while new enhanced services are developed. OmniHub supports a variety of interfaces that enable easy integration of numerous channels,includingTCP/IP,CORBA,SOAP/XML,HTTP,MQ,Tuxedo,PathwayandSNA.

Due to data and channel integration provided by the combination of OmniPayments and OmniHub, the following key features are provided:

•Accesstothedatainrealtime,improvingdataaccuracy, enhancing customer service and reducing process time

•Completeknowledgeofacustomer

•Real-timeaccesstoallinformation,allrelationsofthe customer with the bank

•Businessintelligenceonconsolidatedandreal-timedata gathered by OmniHub

•AmeanstorelateoridentifycustomersacrosslegacysystemsandidentifyVIPcustomers

Addition of new channels and new services is not complex. This can be accomplished with configuration changes and accommodating additional data sets that reflect data from existing legacy services required to be centralizedonOmniHub.

Such data sets can be easily created using the browser-based console. In this way, the bank can rapidly develop and deploy new services across channels to achieve a 360-degree single customer view. Single customer view plays an important role, providing support to multiple transactions across different channels. The common transactions supported as BLMsarelistedhere.Thissetwithzeroorminimumcustomizationcanmeetmanyrequirementsforhandlingcomplex business functionality.

All these business logic modules support the transaction, regardless of channel—enabling OmniPayments and OmniHub to provide a single customer view and offer servicesthatsupporttransactionsacrossATM,POS,IVRand Internet banking, as well as stand-in processing. TheoptionalBLMsareshowninthefigureabove.

OmniPaymentsLegacy ATM/POS solution Other ATM/POS solution

OmniOffers (personalization)OmniSCV (single customer view) OmniSI Server (stand-in processing)

OmniHub

Optional modules

Standard Internet transactions supported:•Balanceinquiry•Fundtransfer•Highyieldaccounttransaction

– auto top, auto transfer, saving plan, account label

•Checkstatusinquiry•Stopcheckpayment•Ordercheckbookonline•Billpayment–immediate,

post-dated•Fundstransfer(own/intra/

inter) – immediate, post-dated•Purchasecashierorder•Purchasedemanddraft•Telegraphictransfer•Onlinemoneyorder•Purchaseofunittrusts•Purchaseofinsurance•Investcredittop-up•IPOapplication•Electronicsharepayment–by

contract, lump sum•Timedeposit–placement•Limitmaintenance•OpenCOE–submitbids,

revise

11

Internet banking transactionsThe OmniPayments solution supports standard Internet banking transaction types. When the transaction is initiated from the Internet banking channel, it is sent to the Omni router module, which involves handling input interfaces from the Internet channel. OmniPayments canhandleTCP/IP,WebSphereMQ,CORBA,SOAP/XMLandPathwayinterfaces.Afteracquiringa transaction, the Omni router module sends it to the securitymodule,whichauthenticatesandauthorizesthe transaction, as well as provides session handling.

Once authenticated, the transaction is sent to the appropriate business logic module. The transaction can be processed locally, or it can be transferred to the backend service for further processing. The business logic module waits for the response from the host; when the host replies, the transaction response is sent to the Omni router, logged and then transferred to the Internet channel.

HP NonStop systemsOpsol chose HP NonStop systems as the exclusive platform for OmniPayments because HP NonStop systems provide enterprise customers with the highest levels of availability, performance and access—in real time. Today, HP Integrity NonStop is used by financial institutions around the world to deliver better business outcomes through:

•Continuousavailabilityfor24/7businessoperations

•Realtime,allthetime,businesssolutionsfortheenterprise

•Standard-basedapproachforinvestmentprotectionand smooth integration

•Simplifiedmanagementthatisbuilt-in

•ReducedITandper-transactioncostsinatrustedNonStop fault tolerant environment

•Simplifiedinfrastructureandlowertotalcostofownership

Most-trusted servers, new form factorFor decades, enterprises have trusted HP NonStop systems to power business-critical 24/7 solutions, recognizingNonStopsystems’distinctadvantagesof unmatched reliability, scalability and availability. Now the HP NonStop server line includes a bladed form factor—the HP Integrity NonStop NB50000c BladeSystem. This fully-configured system can contain up to 16 processors, the same as largest HP contemporary NonStop S-series servers. Based on dual-core Intel® Itanium® processors, the NB50000c includes improved middleware and a new NonStop operating system that:

•Enhancesmultiplefailurefaulttolerance

•Increasesonlinemanageability

•Easesupgrades

•LeveragingIntel’simprovementsinchip-leveldata integrity and the capability to prevent data corruption end-to-end,

•Providesindustry-leadingend-to-endtransactionintegrity for the most reliable data

The NB50000c BladeSystem combines the economies of standards-based, modular computing with all the trusted 24/7 fault-tolerant availability and data integrity of NonStop. The result is an excellent price/performance ratio that includes lower per-transaction cost—making it an ideal choice for financial institutions with very high transaction volumes.

TheNB50000cBladeSystemhelpsorganizationsadapt more quickly to changing business situations, while simplifying the complexity of the IT environment. It serves as an ideal platform for moving to an Adaptive Infrastructure through standards-based, modular computing and next-generation technologies that can accommodate more robust applications for business growth.

Omni foreign currency transaction features:•Providessupportformulti-

currency transactions for all currency known within OmniPayments

•Allowseasysupportforanewcurrency

•Storesthehistoryoftransactionrate over a period

•Currencyexchangeiscarriedout in both forms (i.e. from major to minor and vice versa)

•Canrestrictforeigncurrencytransaction on basis of: Transaction Service Account Customer Time period

•Supportsconversioninbasecurrency, as well as in U.S.D.

•Cut-offtimeisassociatedwithforeign currency transactions

•Providessupportforpastcalculations (i.e. backward calculations)

12

Appendix AForeign currency transactionsA foreign currency is any currency other than the functional currency of the bank or owning institution. The base currency is the currency of the primary economic environment in which an entity operates. Foreign currency transactions can arise when a customer buys or sells goods whose price is denominated in a foreign currency, and borrows or lends funds when the amounts payable or receivable are denominated in a foreign currency.

OmniPayments on HP NonStop systems is designed to support multiple currency environments. It stores all exchange rates and currencies and can add support for additional currencies. As OmniPayments is populated with many standard exchange rates, it can support foreign currency transactions in terms of base currency or in U.S.D. OmniPayments also keeps the history of exchange rates; this is required for any back calculation. Transactions in any currency other than the entity's functional currency are accounted for as foreign currency transactions.

Books of records are maintained in the base currency (i.e., domestic currency or local currency of the bank). A foreign currency transaction is denominated in a currency other than the bank’s base currency. Foreign currency transactions are converted at the exchange rate ruling on the transaction date. The rate used to convert foreign currency assets and liabilities depends on whether the currency risk is hedged.

The OmniPayments and HP NonStop solution supports foreign currency transactions through the currency conversionmodule,OmniBLMs.OmniPaymentsincludes the currency and exchange rate schema, which stores updated rates for these entities.

OmniPayments running on HP NonStop systems processes transactions in multiple currencies, when the local currency of the transaction originator is different from the local currency of the payee, which requires the exchange between the currencies to be hedged at the time of transaction. The system and method enable the transaction originator to receive a final price for the product before the transaction

is performed. The system and method also provide a mechanism for the actual exchange between the currencies of the buyer and of the vendor, such that the aspects of the transaction regarding payment are fully supported. Preferably, online hedging of the currency transaction is performed to reduce the risk involved with predetermination of prices.

To illustrate the method used for determining approval of a multi-currency transaction, consider a situation between a customer and a merchant over a network. Transaction amounts are the amount the customer is paying to the merchant for a product in a first currency. The product price is the price at which the merchant agrees to sell the product in a second currency. The BLMreceivesdatareflectingbothamounts,andthenconverts the first currency to the second currency. The transaction is approved if the converted amount in the second currency is within a risk range, using the prevailing exchange rate. Once the transaction is approved, the approving bank/institution may settle the transaction at its discretion, thereby bearing the risk associated with currency exchange. The parties, however, incur no risk. The customer pays the amount in the first currency and the merchant receives the price in the second currency. These are values known and agreed to by the parties at the time of the transaction.

Foreign currency transactions are recorded on initial recognition in the base currency at the transaction rate (the spot exchange rate at the date of the transaction) between the entity's base currency and the foreign currency.Limitsandexchangeratesareupdatedinthedata store either through the console manually or by running a daily batch job.

The data store (OmniODS) supports multiple currencies by storing exchange rate data and risk limits. Exchange rates are updated manually by using the console,ortheycanbeprocessedasbatchjobs.BLMsuse local date and server date to support multiple time zones,whicharestoredwithintheOmniPaymentsandHP NonStop system.

13

Appendix BCharges/Fees handlingThe OmniHub and HP NonStop solution includes a transaction charging module that calculates charges based on transaction code, channel, user profile and transaction limits. It also manages a periodic fee for the different services opted by the customer. A customer can be charged for a service on a monthly, quarterly or annual basis. The charging module also supports usage-based billing. Its flexible architecture enables banks to easily charge any transaction, service or account, based on usages, periodic basis or a combination of the two.

The services charging module runs one or a combination of rules, depending on the transaction. It is basically a parametric charging mechanism that considers different characteristics and their limits, stored for a transaction type. The module uses one or a combination of methods among segment calculation, upper waiving, lower waiving, linear calculation and class category. All rules are configurable; Omni Console provides the means for configuration. Administrator functionality can be invoked to alter the rates or modify the rule via the web console.

Charges can be applied to groups of transactions based on volume, monetary value bands or segments within a transaction type. Segment calculation is the basic means of charging on a usage basis; different charges apply to each segment. The usage values are divided into segments, which are rated for billing. For example, consider a billing transaction as a bank draft. The draft amount is divided into segments from $0 to $1000, $1000 to $5000, $5000 to $10,000 and is charged with different rates per segment. The segment and the charge are configurable from Omni Console. There is virtually no limit on the number of segments used.

With upper waiving, the parameter is set for charging up to the waiving limit. There is no charge after a certain level of usages. Consider a draft billing transaction that has an upper waive limit of $10,000. The charge for the draft is only assigned below $10,000; so for a draft of $11,000, only the first $10,000 is a chargeable amount.

Lowerwaivingiswhentheparameterissettonotchargeup to the waiving limit. With a parameter as transaction amount and lower waive limit as $1000, there will be nochargeappliedforanamountbelow$1000.Linearcalculation is scalable charging on usage units. In our draft example, the charge can be $10 for every $1000. Means are also provided for discounts.

Any additional parameters can be added from the Omni Console to take effect in the charging process. User type considers user rating, customer, bank employee, etc.

14

Appendix CTransaction logThe OmniPayments and HP NonStop system not only logs a transaction when it arrives at the system, but also logs the transaction at various instances to create a precise lifecycle of each transaction. For basic recovery purposes, four-point logging is used:

1. When a transaction is routed from the channel

2. When a transaction is given to the host

3. When the host replies

4. When a transaction is returned to the requesting entity

Loggingatransactionatallthesestagesisconfigurable as a system parameter, which defines whether logging is to be completed.

Apart from this, the OmniPayments and HP NonStop solution also provides clean-up servers, which clean up records from the transaction log and aggregate records in the database statistics data model. The retention time for transaction log entries is configurable and can be specified as a system parameter. Transactions are retained for the specified period; after that, the required information is transferred to the statistics table. Historic log records are moved from the log to another historic table to ensure that no records are lost. These logs provide valuable business intelligence that can be used to better know the customer, customer behavior and the financial institution’s business growth and performance.

Analysis of the statistical data can enable financial institutionstocapitalizeoncertainsectors.Forexample, companies can run a report on which ATMs handled the highest number of withdrawals/deposits in the last three to four months. Using this report, the institution could justify opening a new ATM nearby, which would boost their revenues in that geographic area and benefit their customers. This example illustrates how transaction log data can be aggregated in a meaningful way to provide important business intelligence. Again, the system parameters for data retention and archival are fully configurable.

The OmniPayments and HP NonStop solution logs every transaction coming into the system—including transactionsfromATMs,POSs,IVRs,Internetbankingandcreditcards.Loggingcanhelpafinancialinstitution understand which channels are busy, which channels are sluggish, which channels are preferred by customers, and much more.

The OmniPayments and HP NonStop solution can be programmed to log any part of the transaction information, such as:

•CustomerID

•Uniquetransactionidentifier

•Usersessioninformation

•Transactionstarttimeandendtime

•Originatingchannelname

•OriginatingsourceIDanddescription

•Transactiondescription

•Transactionstatus(successful/failed)

•Transactiondescriptions

•Customeraccountinformation

This list is not exhaustive. Many additional parameters can be added, depending on the financial institution’s needs.

Loggingalsoincludesinformationabouttheresponsereceived from peer servers that may have been used byvariousBLMs.Thetransactionisloggedonceasitis sent to a peer server or middleware, and then again when the response is received. The OmniPayments and HP NonStop solution also stores the response, updates the status of the transaction, and logs the transaction status as successful or failed. The description of the status is also logged, such as the reason for failure, description of failure, status for post-dated transactions, orotherinformationthatmustbeselectedbyaBLM.Reversal transactions are also logged in the system.

Each transaction log entry has a unique identifying number. The console provides a view of the transaction log data and supports report generation. The enriched web console can search on various aspects of an entry, such as customer information; transaction start time or end time; transaction information such as code and status; channel name; and source and service name.Variousprintingoptionsarealsoavailable.

After a specified period of time (which is fully configurable), the transaction log data is moved to long-term storage media. This action can be complete during routine system maintenance. Using the OmniPayments scheduler web console, financial institutions can set up automatic e-mail reminders or alerts to remind system administrators to complete this activity. Requests to retrieve logs can also be issued through the console. Once completed, the OmniPayments and HP NonStop system will inform the user who needs the reports or initiated the inquiry on the log.

The OmniPayments and HP NonStop system can temporarily store retrieved transactions from the archived log. The console enables users to view retrieved archived logs. All normal reports and queries can be issued on the transaction log, and they can be printed as normal log reports.

15

Appendix DPost-dated transactionsPost-dated transaction handling is basically scheduling a transaction for a future date and activated when post-dated transactions follow the path of normal transaction processing. Post-dated transaction handling is primarily for Internet banking customers making post-dated bill payments and transfers, but can also be requested through any other channel. OmniPayments and HP NonStop can store transactions in the operational data store for a specified period of time. The OmniPayments and HP NonStop solution can also be used as a data warehouse to store all post-dated transaction details.

Running on a time-out basis, OmniPayments continuously polls post-dated transactions. Whenever OmniPayments finds a post-dated transaction, it marks the transaction as an online transaction, using the current date as the effective date. The transaction is then sent to the Omni Router, which in turn sends it to the appropriate service. If the transaction must be routed to the host, then it will be sent to the host legacy system, where the defined logging is assigned. Upon receiving a response from the host, the status of the transaction is updated and processing is completed.

Any changes made to the pending transaction are logged. The scheduled post-dated transaction can be cancelled or all characteristics can be updated. Complete revisal and reschedule is possible for any post-dated transaction. Post-dated transactions are cleared by administrator functionality only.

Workflow for post-dated transactions is as follows:

•Fetchtheentryfromthetransactionwarehouse

•Verifythecustomerstatusandrelatedsecurityinformation against the database before proceeding

•Aftervalidatingthetransaction,processthetransaction as a normal real-time transaction using business intelligence servers with transaction logging

The key feature of the post-dated transaction is being processed as a normal, real-time transaction. Doing so ensures all business and security functions are applied at every stage of the transaction.

OPEN SOLUTIONS ARCHITECTS

oops L

OPSOL SOLUTIONS

Technology for better business outcomes

To learn more, visit www.hp.com www.opsol.com

©Copyright2009Hewlett-PackardDevelopmentCompany,L.P.Theinformationcontainedhereinissubjecttochangewithout notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Intel and Intel Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

4AA2-5453ENW, October 2009