Opsol OmniPayments and HP NonStop

systems
Powering the next-generation of payment systems

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

op
soL

OPSOL SOLUTIONS
OPEN SOLUTIONS ARCHITECTS

Executive summary
Introduction
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 customerfacing channels. For example, an alternate offering
could be personal insurance that has been tailored for
a specific individual.

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
Supports web ATM and standard ATM/POS devices
Allows for customization of services delivered via
web ATMs
Provides a comprehensive set of payment services
and optional system of record (SOR) stand-in
Delivers one of the best service levels in the industry
Leverages a proven operational system that supports
over 8000 ATMs
Supports optional integration with legacy systems
to deliver a single customer view over multiple
channels, improved fraud detection/prevention, and
other advanced features

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 Internetsourced transactions.

OmniPayments

ATM

Solution overview
OmniPayments and HP NonStop systems provide a
comprehensive solution for financial institutions to
acquire, authenticate, route, switch and authorize
transactions 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, called business logic modules (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
authorization for an action on a customer card or
an account from a transaction authorizer (issuer).
The transaction is then routed between the originator
and the authorizer. The HP and Opsol solution can
handle 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.

POS

Switch

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
institutions of all sizes. By combining standards-based
NonStop infrastructure technologies with leading-edge
Omni applications, HP and Opsol offer financial
institutions powerful, flexible payments solutions that
can resolve tough business challenges todayand
dynamically adapt as those needs change.

HP and Opsol advantage

Providing best-practice consulting and implementation
services, you can work with HP and Opsol at
every stage of your payments projectfrom 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.

Payment platforms
Legacy ATM

Web ATM

OmniPayments/POS
architecture diagram

POS
transactions

The OmniPayments solution

Overview
The Opsol OmniPayments solution is an open, SOA,
standards-based architecture that delivers reliable and
scalable capabilities for todays payments industry. The
structured design allows for the addition of SOA BLMs
that 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
and authorize financial transactions across multiple input
and back-end channels with value-added services.
OmniPayments allows the transaction originator to
initiate a payment, make a request, and receive the
authorization for an action on a customer card or an
account from a transaction authorizer. OmniPayments
routes the transaction between the transaction originator
and the transaction authorizer. It can handle both on-us
and outside transactions.

Back-end
system of
record
(HOST)

OmniPayments

Payment networks
e.g. VISA, Mastercard,
AMEX, NETS

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).
The web ATM functionality enables customization of the
ATM screen on a per-customer basis. Each customer can
define default screens and preferred cash transaction
values. Since many customers prefer speed over function
at the ATM, customization can improve customer
satisfaction, as well as increase server, network and
ATM utilization.
Customization capability also enables an institution to
make 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.

OmniPayments
console

Payment platforms
OmniDash

Web ATM

POS
transactions

Infrastructure management and security

OmniPayments 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.

OmniCrypto

Back-end
system of
record
(HOST)

OmniPayments

Payment networks
e.g. VISA, Mastercard,
AMEX, NETS

Interchange/switch interfaces
The 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.

OmniPayments

Legacy ATM
Tx Acquisition

HOST

Tx Router

Tx Authentication

Payment switch

Auth Data

Web ATM

POS
transactions

Tx Logger

Payment networks
e.g. VISA, Mastercard,
AMEX, NETS

Standard ATM transaction types

supported:
Withdrawal
Fast cash withdrawal
preset account and value
Withdrawals with account
and value selection
Balance inquiry
Cash deposit
Credit card payment
ID application
Statement request
Mini-statement
Mobile phones top-up
payments
Advanced ATM transaction types
supported:
PIN change
Customizable fast cash
withdrawal
Customer defines fast cash
amount and account
Invoice payments
Balance inquiry
Account-to-account transfer
orders
Advertisement and marketing
actions at ATMs
Card expiration warning
Retained card warning
Mobile operators billing

"On-us" transactions
In on-us transactions, the acquiring device and
the account holder belong to the issuing bank. "Offus" 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 set
The 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
to the host for authorization processing. When the host
responds, 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
the stand-in BLM, which typically provides negative
authorization and logs the transaction for later host
update. The customer receives his cash (see page 11 for
more details on the stand-in processing function).

OmniPayments
console
Web ATM

TCP/IP

Core banking

OmniPayments router
OmniPayments services
Acquisition
Authentication
Logging
Payment switch

Single customer view

Offers
Encryption
Customer contact

TCP/IP

Host adapter

ODS
Business intelligence
DM

Standard POS transaction types

supported:
POS purchase
Balance inquiry
Pre-authorizations
Cash back
Check transactions
Cash advances
Advanced POS transaction types
supported:
Cash card top-up
Cash card refund
Merchandise returns
Purchase adjustments
IVR transaction types supported:
Balance inquiry
Fund transfer/third-party fund
transfer
Bill payment
Check status inquiry
Stop check payment
Order check book online
Fixed deposit placements
Fixed deposit withdrawals
ATM PIN replacements
ATM card activation
IB PIN replacements
IB service activation
Update mobile number for
SMS
Credit card balance inquiry
Credit card statement inquiry
Credit card temporary increase
Credit card request for
statement
Branch teller transaction types
supported:
Account inquiry
Cash deposit/bulk cash
deposit
Cash withdrawal
Fund transfer
Check deposit
Purchase cashier order
Purchase demand draft
Telegraphic transfer
Bill payment
Forex sale and purchase
Time deposit placement

HP NeoView

POS transactions
OmniPayments 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 transactions
OmniPayments supports standard and advanced
interactive voice response (IVR) transactions (listed
below). IVR messages can be received over TCP/IP
or SNA, CORBA, SOAP/XML, WebSphere MQ and
Pathway interfaces. Handling these IVR transactions is
fundamentally 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 transactions
Most 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 design
Transaction processing is completed using SOA BLMs. In
fact, OmniPayments uses BLMs to complete all business
functions as a set of services. A BLM may also use
services provided by peer systems within the institution
(see figure above).

DB

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.
Each BLM is responsible for communicating with the
logging function. Using the console, each BLM is
configured to ensure it sends the desired macro data to
the logging function.
Transaction logging
In every situation, OmniPayments employs four-point
transaction logging to ensure recovery and failure
analysis, if required:
Incoming copy
Outgoing copy to peer system
Incoming copy from peer systems
Outgoing copy to requesting channel
In addition, other transaction details can be logged
for later analysis. Each BLM can be configured to
log 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).

Channels

TCP/IP

OmniPayments

Hosts

Host Status Monitor

ATM
IVR
Internet

SIS-Q
ISO
8583

Adapters

Auth
ODS

Tuxedo,
Cobra
MQ
FTP

Stand-in processing when host is unavailable

Optional OmniPayments functions

Stand-in processing
As discussed above, online banking takes many
formsthe 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.

If the host or system of record is unavailable, the standin 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
that file and authorized accordingly. Transactions are
placed into the stand-in queue (SIS-Q), and then posted
from the queue back to the host on its return. The standin function continues until the host server is up to date,
at which point original processing routing resumes.

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
functions is authorization; but OmniPayments can be
enhanced 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.

Standard credit card transactions

supported:
Purchase authorization
Merchant reversal
Adjustment transaction
Cash advance
Common transactions supported
as BLMs:
Account inquiry
Balance inquiry
Account statement inquiry
Account transaction inquiry
Block status inquiry
Block status modification
Bill payee add
Bill payee delete
Bill payee inquiry
Bill payee confirmation
Cash deposit
Online purchase
POS purchase
Credit card cash withdrawal
Debit card withdrawal
Card to card transfer
ATM cash withdrawal
Credit card bill payment
Credit card deposit
Credit card account statement
inquiry
Credit card account
transaction inquiry
Customer add
Customer inquiry
Customer payee add
Customer payee delete
Customer payee inquiry
Customer transfer delete
Customer transfer inquiry
Passbook update
Checkbook request
Check status inquiry
Token request
Department account statement
inquiry
Statement type modification
Loan account transaction
inquiry
Payment add
Payment cancel
Payment inquiry
Payment modification
Recurring payment add
Recurring payment cancel
Recurring payment inquiry
Recurring payment
modification
Reward account statement
inquiry
Transfer add
Transfer delete
Transfer modification
Transfer inquiry
Claim account inquiry
Change PIN
Cash card refund
Application for ID
Application for service
activation
Stop check payment

Optional dashboard functions

Managing 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
functionsto 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.

Credit card transactions

Handling 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.

OmniPayments is readily configurable to handle

disasters, with many options that cover:
Single site dual servers
Multi-site dual servers
Multi-site dual servers with lock-step transaction
processing ensuring no transaction is lost
Multi-site with multiple servers
Multi-server configuration can be active/active or
active/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.

Legacy ATM/POS solution

OmniPayments

Other ATM/POS solution

OmniHub

OmniSCV (single customer view)

OmniOffers (personalization)

OmniSI Server (stand-in processing)

Optional modules

Standard Internet transactions

supported:
Balance inquiry
Fund transfer
High yield account transaction
auto top, auto transfer,
saving plan, account label
Check status inquiry
Stop check payment
Order checkbook online
Bill payment immediate,
post-dated
Funds transfer (own/intra/
inter) immediate, post-dated
Purchase cashier order
Purchase demand draft
Telegraphic transfer
Online money order
Purchase of unit trusts
Purchase of insurance
Invest credit top-up
IPO application
Electronic share payment by
contract, lump sum
Time deposit placement
Limit maintenance
Open COE submit bids,
revise

Channel integration
A 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
including ATM, POS, teller, IVR and Internet banking
channelsand 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, including TCP/IP, CORBA, SOAP/XML, HTTP,
MQ, Tuxedo, Pathway and SNA.

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
centralized on OmniHub.
Such data sets can be easily created using the browserbased 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
BLMs are listed here. This set with zero or minimum
customization can meet many requirements for handling
complex business functionality.
All these business logic modules support the transaction,
regardless of channelenabling OmniPayments and
OmniHub to provide a single customer view and offer
services that support transactions across ATM, POS, IVR
and Internet banking, as well as stand-in processing.
The optional BLMs are shown in the figure above.

Due to data and channel integration provided by the

combination of OmniPayments and OmniHub, the
following key features are provided:
Access to the data in real time, improving data
accuracy, enhancing customer service and reducing
process time
Complete knowledge of a customer
Real-time access to all information, all relations of
the customer with the bank
Business intelligence on consolidated and real-time
data gathered by OmniHub
A means to relate or identify customers across
legacy systems and identify VIP customers

10

Omni foreign currency

transaction features:
Provides support for multicurrency transactions for
all currency known within
OmniPayments
Allows easy support for a new
currency
Stores the history of transaction
rate over a period
Currency exchange is carried
out in both forms (i.e. from
major to minor and vice versa)
Can restrict foreign currency
transaction on basis of:
Transaction
Service
Account
Customer
Time period
Supports conversion in base
currency, as well as in U.S.D.
Cut-off time is associated with
foreign currency transactions
Provides support for past
calculations (i.e. backward
calculations)

Internet banking transactions

The 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
can handle TCP/IP, WebSphere MQ, CORBA,
SOAP/XML and Pathway interfaces. After acquiring
a transaction, the Omni router module sends it to the
security module, which authenticates and authorizes
the 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 systems
Opsol 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 accessin real
time. Today, HP Integrity NonStop is used by financial
institutions around the world to deliver better business
outcomes through:
Continuous availability for 24/7 business operations
Real time, all the time, business solutions for the
enterprise
Standard-based approach for investment protection
and smooth integration
Simplified management that is built-in
Reduced IT and per-transaction costs in a trusted
NonStop fault tolerant environment
Simplified infrastructure and lower total cost of
ownership

Most-trusted servers, new form factor

For decades, enterprises have trusted HP NonStop
systems to power business-critical 24/7 solutions,
recognizing NonStop systems distinct advantages
of unmatched reliability, scalability and availability.
Now the HP NonStop server line includes a bladed
form factorthe 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:
Enhances multiple failure fault tolerance
Increases online manageability
Eases upgrades
Leveraging Intels improvements in chip-level
data integrity and the capability to prevent data
corruption end-to-end,
Provides industry-leading end-to-end transaction
integrity 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
costmaking it an ideal choice for financial institutions
with very high transaction volumes.
The NB50000c BladeSystem helps organizations
adapt 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.

11

Appendix A
Foreign currency transactions
A 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 banks 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
conversion module, Omni BLMs. OmniPayments
includes 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
BLM receives data reflecting both amounts, and then
converts 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. Limits and exchange rates are updated in the
data 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, or they can be processed as batch jobs. BLMs
use local date and server date to support multiple time
zones, which are stored within the OmniPayments and
HP NonStop system.

12

Appendix B
Charges/Fees handling
The 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 usagebased 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.

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.
Lower waiving is when the parameter is set to not charge
up to the waiving limit. With a parameter as transaction
amount and lower waive limit as $1000, there will be
no charge applied for an amount below $1000. Linear
calculation 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.

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.

13

Appendix C

Customer ID

Transaction log
The 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:

Unique transaction identifier

1. When a transaction is routed from the channel

Transaction description

2. When a transaction is given to the host

Transaction status (successful/failed)

3. When the host replies

Transaction descriptions

4. When a transaction is returned to the requesting

entity

Customer account information

Logging a transaction at all these stages is

configurable 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
institutions business growth and performance.
Analysis of the statistical data can enable financial
institutions to capitalize on certain sectors. For
example, 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.

User session information

Transaction start time and end time
Originating channel name
Originating source ID and description

This list is not exhaustive. Many additional parameters

can be added, depending on the financial institutions
needs.
Logging also includes information about the response
received from peer servers that may have been used
by various BLMs. The transaction is logged once as it
is 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,
or other information that must be selected by a BLM.
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. Various printing options are also available.
After a specified period of time (which is fully
configurable), the transaction log data is moved to longterm 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 solution logs

every transaction coming into the systemincluding
transactions from ATMs, POSs, IVRs, Internet banking
and credit cards. Logging can help a financial
institution understand which channels are busy, which
The OmniPayments and HP NonStop system can
channels are sluggish, which channels are preferred by
temporarily store retrieved transactions from the
customers, and much more.
archived log. The console enables users to view
The OmniPayments and HP NonStop solution can
retrieved archived logs. All normal reports and queries
be programmed to log any part of the transaction
can be issued on the transaction log, and they can be
information, such as:
printed as normal log reports.

14

Appendix D
Post-dated transactions
Post-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:
Fetch the entry from the transaction warehouse
Verify the customer status and related security
information against the database before proceeding
After validating the transaction, process the
transaction 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.

15

Technology for better business outcomes

To learn more, visit www.hp.com
www.opsol.com
Copyright 2009 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change
without 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

op
soL

OPSOL SOLUTIONS
OPEN SOLUTIONS ARCHITECTS