We’ve all heard this story before.  Something, somewhere, on your ATM or POS network is causing your end-customer’s transactions to slow down or fail, but you don’t know where the issue is.  Sometimes you don’t know how long the problem has existed for, how many transactions are being affected, or whether the problem is related to a specific ATM or POS terminal, a service such as check imaging or a loyalty rewards program, an interbank connection, or an EFT network.  Perhaps it is your payments switch or an internal network communications issue?  Regardless, the longer the guessing game goes on, the greater the impact on support costs, revenue generation and customer loyalty.

A business transaction management (BTM) solution, coupled with your ATM monitoring and deep-dive application performance management tools, is the most effective way for ATM and IT operations teams to work together and meet these challenges head on.  BTM solutions, also commonly referred to as network-level transaction monitoring solutions, extend monitoring beyond physical service terminal performance, to a systems wide view into how all the various terminals, services, networks and third party connections are responding.  A performance management strategy that combines deep dive ATM or POS performance metrics, transaction response times, and real-time analytics on the end customer experience is the key to cost effective management, timely problem resolution and consistent end-customer service reliability.

Watch this 3 minute video to learn how IT operations, ATM operations and applications support teams can use transaction monitoring tools to extend visibility beyond the ATM or POS.

Not so surprising, many IT folks felt it was tough to directly correlate customer acquisition, satisfaction and loyalty to any one application-focused product or network monitoring solution.  Many also dismissed the traditional business model approach of trying to equate a software management purchase to a reduction in IT staff headcount as “old-school”.

So that left me thinking…is getting the green light to invest in a new performance management solution still about proving out ROI in less than a year?  Or is it more about convincing senior management that this is the missing “piece of the pie” needed to position IT operations as a strategic asset that can optimize end-to-end business performance, resolve issues before they affect revenue-generating services, and ultimately guarantee an amazing end customer experience?  In other words, what else could your people do if you eliminated more unpredictable, productivity-sapping firefights in the future?  Or perhaps I am totally out to lunch, and it’s really as simple as the old “reactive” saying that you only sell umbrellas when it rains?

The answer would seem to vary, depending on who you are talking to and whether you are in a reactive or proactive situation, so it’s probably wise to cover all tracks.

If you are faced with a “reactive” situation, and many of us have been there, where application, network, or third party service outages and slow response times are resulting in high support costs, a loss of customers and a loss of revenues, justifying the purchase of a performance solution that can quickly detect and isolate the root cause of the issue becomes a lot easier.

It’s when you are not putting out a fire, but proactively preparing for that “what if” scenario where justifying the ROI of a performance management tool can become a bit tougher to do. Most CTO’s business objectives include elements of greater operational efficiency, reduced support costs and improved quality of service (QoS) or end customer experience.  Looking at the business impact your new performance management solution will have on increased staff productivity, reduced mean-time-to-repair (MTTR), decreased service level agreement (SLA) incidents, and a reduced number of customer-reported service outages should provide the justification you need to move forward with your purchase.

If you’re looking at all of this from the CFO’s perspective, then it becomes a question of payback and usually an ROI in less than a year. In the reactive case, this is a simple calculation – how much revenue can you recapture? How much can you reduce support costs? In the proactive case, the question you’re really trying to answer is – how does our APM investment help us grow the business without growing our staff costs and in-house development efforts in a direct linear relationship? If you can answer this question, then you’re talking about margin growth. And that’s a great way to measure payback.

Every corporation weights the importance of these areas based on their own environments, business processes, and circumstances. If you are interested in receiving a more detailed copy of our business impact models, please feel free to email me:  sgorkoff@inetco.com.  If you have other ideas, please chime in your thoughts, too!

So I asked him a question:

“Why is transaction monitoring so important to you?”

His answer (paraphrased):

“We have a culture of operational efficiency across our organization and especially in IT – your software makes my people more efficient. It largely automates one of the most unpredictable and productivity-sapping IT functions for my operations team: problem isolation.  What’s the source of the problem and who should work on it? You do that really well for all our payments channels. If I can apply the same process to more applications, we just get more efficient, and in a culture that values efficiency, I have a compelling business case to deploy more of your software.”

It was my turn to get excited. I asked him how he translates efficiency into a business case.

“We’re a financial services company. Every application matters because they either make money or automate a complex process that costs a lot more money to execute manually. When we have an application performance issue, it’s all hands on deck – my senior network, server, database, banking application support leads all pretty much drop what they’re doing and start digging. But the problem is likely only in one of those places, right? So 3 of the 4 are wasting their time. Not only are they wasting time, but the whole process is stealing time from other projects they have on their plate. In a culture of efficiency, this kind of waste is intolerable. My business case is simple: transaction monitoring software lets more of my people, spend more of their time, working on the projects that matter to the business.”

Transaction monitoring replaces slow, trial and error problem isolation methods with a fast, data-driven approach that improves efficiency AND delivers better availability and performance.

Besides the simplicity of his business case, the other thing that is revealing is how many people in his organization depend on our software. While the IT operations team “owns” the INETCO Insight deployment, everyone uses it.

This quarter, I’m going to write a series of articles on why transaction monitoring is so important to the various functional teams in an IT operations department, from application support, to database administrators. I’ll explore how each team can use transaction monitoring and how it helps foster a culture of operational efficiency.

Stay tuned, and if you would like to share why transaction monitoring matters is important to you, we would love to hear from you.  Simply drop a line to: insight@inetco.com

Featured Video

Managing Applications within Virtual, Cloud and Mobile Payments Environments (2:37 min)

WATCH THE VIDEO NOW >>

Main Article

Why should banks, ATM deployers and payment processors care about transaction response times?

READ THE FULL STORY >>

Success Story

How Moneris improved customer service reliability through 65% faster problem isolation

READ THE CASE STUDY >>

Tips N’ Tricks

Introducing the Unified Transaction Model (UTM)

LEARN MORE >>

Featured Whitepaper

The Unified Transaction Model – Making Sense of Transaction Complexity  (Published February 2012)

DOWNLOAD WHITEPAPER NOW>>

Featured Webcasts 

• Introducing the Unified Transaction Model – Making sense of big transaction data and multi-hop transaction complexity (March 2012)

• Moneris Solutions and INETCO Present: How Transaction Monitoring Improved Visibility into the End Customer Experience  (February 2012)

• NCR and INETCO Present: Demystifying the Top 5 Myths in ATM Transaction Monitoring (December 2011)

What’s News

•  INETCO Awarded Patent for Multi-reader, Multi-writer Lock-Free Ring Buffer Algorithm
• INETCO Takes Transaction Monitoring Mainstream with INETCO Insight 5
• E-Global selects INETCO Insight as their Business Transaction Management Solution
• INETCO Extends Real-time Transaction Monitoring Capabilities to All AMQP 1.0 Applications
• NCR and INETCO Forge Complimentary Software Relationship for Holistic ATM and Transaction Monitoring

Our Favorite Blog Posts

• 2011 – A Winning Year for INETCO!
• How Moneris uses transaction-level monitoring to prep for peak times and Black Friday
• Beyond Layer 7 – Defining the next step in network-based APM

Overheard

“Transaction monitoring can act with amazing speed and accuracy to find what amounts to a needle in a haystack…The INETCO Insight solution can tell you exactly — it was this transaction on that server at that time of day…”
– Robert Johnston, Marketing Director of ATM Software at NCR

Layer 7 is responsible for managing the communication between applications. This communication is achieved by passing messages. So, analyze the messages and you can tell a lot about how the applications are behaving, without knowing anything about the internals of the applications. This is the root of an effective network-based approach to APM.

It turns out it’s easy to do for a single protocol (e.g. HTTP, or FIX), but really hard to do for multiple protocols. In fact, only three companies I know of do it: INETCO, ExtraHop, and HP.

Step 1:  Reconstructing exchanges between servers

We can all monitor message flow between applications (sometimes called “full stream re-assembly”) for multiple protocols. This is Layer 7 monitoring. To do this, the system has to recognize various application messages as they present on the network and the syntaxes used to structure the information in the messages. Basically, it has to reassemble messages (taking into account duplicates, missing parts, and sequencing) and then tear apart the messages to get at the interesting information by parsing, using regex, or, or by some other technique. INETCO Insight uses a table driven decode approach, which handles subtle variations in message formats and encodings more elegantly, allows for more reliable consistent recognition of message types, and allows marking of particular message details at different security levels.

This first step is a major leap forward for network-based APM. You can begin to recognize types of messages, extract important details like dollar amounts, SQL statements, and customer numbers. A few years ago you could only have dreamed of doing these kinds of things without agents inserted directly into the application code.

Step 2:  Reconstructing individual end-to-end transactions

But only one of us can use all this information from the first step to re-construct transactions – to go beyond Layer 7. To do this, the system has to compare messages against a set of semantic models for each protocol (taking into account timings, errors, etc.) to recognize when a meaningful bit of work has been accomplished – a transaction. Then it has to compare these single link transactions against another set of semantic models to pull together a multi-link transaction. If you’re an avid reader of our blog, this should sound like the INETCO Unified Transaction Model (UTM).

If you have a small set of applications, each running on dedicated infrastructure, and you are not particularly interested in end user service levels, you can get away with Layer 7 monitoring…for awhile.  If you have a large set of applications, run multiple applications on shared infrastructure or virtual environments (e.g. a private Cloud, an application server or database cluster), or are accountable to transaction SLAs, you have to go beyond Layer 7.

I’m reminded of a classic quote from a Canadian hockey star (Wayne Gretsky). When asked how he was so successful, he replied: “I skate to where the puck is going to be, not where it has been.” It’s going beyond Layer 7. INETCO Insight is already there.

For more information on INETCO Insight, read the product sheet.

The basic UTM implementation comprises four levels:

• Business level – business processes that employ applications
• Application level – end-to-end applications interacting with users
• IT services level – inter-operating processes running on nodes
• Network level – nodes with interfaces connected via a network

The network level is the most elementary. It corresponds to a distributed network connected infrastructure of servers (or virtual machines).  Each server constitutes a node in the network level where the nodes are inter-connected via networks.  The UTM describes a link as any pair of nodes that are communicating.   The nodes exchange packets that define network messages.  Sets of exchanged packets compose link transactions.  A link transaction defines a network event such as a connection setup or tear down, or the transfer of a data payload between nodes.

The service level describes IT services.  Each service is at least a pair of processes, each running on a network node, exchanging application messages.  An IT service represents a specific set of functionalities that may be employed by other services.  Each service is composed of one or more network links and a collection of inter-connected services forms a service topology.  A specific exchange of application messages between the nodes of an IT service defines a service transaction.  A typical service transaction is a request/response message pair between a browser client and a Web service.

The application level defines end-to-end applications in terms of an end-user. An application is composed of one or more IT services that are configured to inter-operate.  In most cases, a given application is defined by a particular group of end-users who are interacting with the system via an interface service (ex. Web service, thick client, mobile).  The end-user performs actions at the interface that subsequently triggers transactions within other services.  For example, an end-user might log in, select an item for download, or perform a search.  The set of service transactions related to a specific end-user action composes an application transaction.

The business level describes the activities of an end-user in terms of a particular business goal.  A business has certain objectives which are at least partially fulfilled through the interaction of users with applications.  A sequence of end-user actions may result in a high level goal being achieved – for example, the transfer of money from one bank account to another, the purchase and delivery of a book, or the answer to a question such as the birth date of 3^rd president of the United States.  An end-user will follow a series of steps or a workflow to to achieve the goal.  Each step accomplished through an application corresponds to an application transaction.  A business transaction then is composed of a set of application transactions.

Implemented in a network-based transaction monitoring or business transaction management system, the UTM defines and organizes different transaction types.  It provides a means for mapping the services and infrastructure elements of a distributed application into distinct and recognizable entities.  The network traffic between nodes provides the basis for constructing transaction events according to type and relating them to the elements of the resulting IT service topology across a hierarchy of levels.   As a direct consequence, both the statistical and individual performance of transactions at a high level can be directly related to performance at lower levels – for example, measures of degraded end user experience can be traced to poorly performing services or even to network issues arising between services.

Consequently, application operations teams can constantly monitor the end-to-end performance of an application while maintaining detailed shareable information at the level of servers and the network.  Degraded performance is quickly detected and causes identified and isolated.  Further, the UTM provides for distinct performance metrics on each of the levels so that different teams can measure system performance in terms specific to their responsibilities – network, service, application and business.

The UTM framework transforms the complexity and opacity of modern applications into ordered and visible meaning.  It maps physical and virtual IT infrastructure into well-defined entities that have explicit relationships with one another within a hierarchical framework.   Further it defines the functional nature of applications that run on the infrastructure and the types of events that take place within the framework.  The events are kinds of transactions that take place at different degrees of granularity, with higher-level transactions composed of lower-level transactions.  With this approach, the UTM can account for performance at multiple levels of the distributed application, from the network to the service components to the end-user experience, and simplify troubleshooting and diagnostic processes.

If you are interested in learning more about the Unified Transaction Model (UTM) , you can watch the video below, read the whitepaper, or watch a recording of the webinar held Thursday, March 8th. 

Click here to view the embedded video.

So what’s next?

According to Garbani, now that APM tools have the ability to collect data from multiple sources and understand the mapping of the transactions, we need more intelligence to interpret the data from different sources in a meaningful way.

To that end, INETCO has introduced the Unified Transaction Model (UTM) – a means to make sense of Big Transaction Data and efficiently bring deeper analytics to APM solutions.

Transactions provide critical information about the end user experience, individual applications and network infrastructure components.  The Unified Transaction Model (UTM) helps IT operations and application service teams to analyze application response times and network behavior in relation to the specific business process or task that the end user is trying to perform.

The Unified Transaction Model is expressed in four distinct aspects:

• A hierarchical model which defines system infrastructure components, their properties, actors, inter-dependencies, relationships, events (messages and sub-transactions), and the overall business process;
• A mapping and configuration process whereby the model structure is applied to a specific IT system in terms of the network topology;
• A real-time correlation process that constructs instances of events (e.g. transactions) at each level of the hierarchy, selecting the events from the lower level (e.g. messages) to aggregate in terms of the topological model
• An analysis of the events at each level with respect to metrics of performance specific to each level.

The key to the Unified Transaction Model is its structured and hierarchical approach to transactions.  Transaction types are defined according to a series of nested levels.  The entities at a given level are composed of entities from the level below.  For example, an application can be viewed as composed of one or more functional IT services such as a user interface, business logic, and a datastore.  And each IT service is composed of one or more servers inter-connected by network links.  Events at each level are a type of transaction that are similarly composed of transactions from the level below – exchanges of application messages are composed of network-level exchanges of packets.

The basic UTM implementation comprises four levels:

• Business level – business processes that employ applications
• Application level – end-to-end applications interacting with users
• IT services level – inter-operating processes running on nodes
• Network level – nodes with interfaces connected via a network

The UTM framework transforms the complexity and opacity of modern applications into ordered and visible meaning.  It maps physical and virtual IT infrastructure into well-defined entities that have explicit relationships with one another within a hierarchical framework.   Further it defines the functional nature of applications that run on the infrastructure and the types of events that take place within the framework.  The events are kinds of transactions that take place at different degrees of granularity, with higher-level transactions composed of lower-level transactions.

Be sure to check out Part 2 of this blog next week.

If you are interested in learning more about the Unified Transaction Model (UTM) , you can watch the video below, read the whitepaper, or sign up for our thought leadership webinar being held Thursday, March 8th at 9am PST. 

Click here to view the embedded video.

Why should banks, ATM deployers and payment processors care about transaction response times?  Because your customers do.  Because multi-channel payment environments are a reality.  Because virtualization and the Cloud changes everything.  Take your pick.

I recently submitted a blog posting on transaction response times to a certain LinkedIn banking technology group for posting.  The comment back was, “Please only post Payments related discussions per the group rules.”  My first reaction was to spit out my half sweet, non-fat, extra-hot latte I got from my favourite Starbucks barista, Jory.  My second reaction was to think, “Hmm…is it possible I dove too deep into the details, again?”

Seriously, here is round two – a slightly less “geeked out” version of why people in the payments industry should care about end-to-end transaction response times:

Reason #1:  Because your customers do.

Whether it is an online banking interface, a mobile application, or an ATM, POS, or other type of self-service kiosk, customers care about three things:  consistent service quality, timely content/service delivery and security.  If you cannot deliver on all of these, you run a higher risk of losing a customer’s trust and ultimately, their business.   And this is why you need the ability, at anytime, to answer the question, “How are our services performing in the eyes of my customers?” 

Monitoring end-to-end transaction response times makes it much easier to do this.  It is a common metric across all consumer facing channels and services that can reflect what the end customer is experiencing.  Visibility into transaction response times will speed up your ability to spot performance issues affecting service deliverability and availability, such as:

• Infrastructure performance issues – Are there bottlenecks or communication issues on the network?
• Service performance issues – Are there certain online banking services, mobile services or other services offered through your ATM, POS or self-service kiosks that are either slow to respond or not responding at all?)
• Unsuccessful hand-offs – Is there an issue with one of your customer facing device interfaces, third party service providers, interbank or EFT connections?

Reason #2:  Because multi-channel payments environments are a reality. 

I was recently on a call with Ed O’Brien, Director of Banking Channels for the Mercator Advisory Group, and Robert Johnston, Marketing Director of ATM Software at NCR.  Both confirmed that multi-channel self-service environments are a growing reality and causing a whole new level of complexity that ATM and other device monitoring solutions were not built to manage.  Let’s consider some possible multi-channel scenarios:

Multi-functional ATM/Video streaming channel combo – A bank has a rural area branch presence, but it is too expensive to retain an insurance expert at the physical location.  By linking the rural branch to a call center via video conference functionality that is built into a multi-functional ATM, customers would be able to access insurance policy services.

Multi-functional ATM/E-commerce channel combo – You go to a multi-functional ATM to deposit a cheque and take out some cash.  As soon as you insert your card, a targeted e-commerce advertisement comes up based upon your geographic location and card purchase patterns.  You select yes to the offering (your chequing account will be automatically debited and your purchase will be directly mailed to you), and continue on with your banking.  You are then given the intelligent option to withdrawal your “usual” transaction amount, and are asked whether you would like paper receipts, moving forward.

Multi-functional ATM/Mobile banking channel combo – You are doing some banking via your mobile phone application.  You decide to pre-stage your mobile transaction on your phone, and go to an ATM.  Using near field communication (NFC), your mobile phone communicates with your ATM, and your transaction gets completed.  This scenario can also go the other way, where someone in a different city has deposited money into the ATM, then sent you a one-time pin number on your mobile phone so that you can withdrawal the cash.

Managing these types of interactions across multiple services and channels requires a different way of thinking.  There are more transaction types, service applications and third party hand-offs than ever before.   This growing complexity can definitely make it more challenging to authenticate a transaction in a timely, secure manner.

Transaction response times offer IT, application services, and ATM operations early warning that something is going wrong at the network communications level, a particular service or device, or third party hand-off.  By breaking down the round-trip transaction rate on a hop by hop basis, it becomes easier and more efficient to isolate exactly where and why issues are occurring – anywhere along a transaction path.

Reason #3:  Because you have critical service applications running in virtual environments. 

Cloud and virtual infrastructures are major game changers for how IT, application and ATM operations manage services.  When we start talking SaaS or virtualized data center environments, traditional key performance metrics such as CPU utilization, memory, disk input/output, network bandwidth and required storage input/output go out the window.  In these types of environments, you need to be thinking about ways to control latency and response time issues.

Transaction response times will give IT, application and ATM operations team visibility into both application and infrastructure latency issues.  They give you the ability to start thinking beyond uptime and traditional ticket closure metrics as a way to measure successful service delivery levels, and tie your SLA’s to what should matter the most:  What the end customer is experiencing across all your services.

So to recap, monitoring transaction response times will help you deliver on the following high-level banking priorities:

• Delivering the best, most consistent end customer experience across all ATMs and all other consumer facing channels possible
• Ensuring top performance and uptime reliability of an increasingly diverse portfolio of multi-vendor services offered through ATM, POS, and self-service kiosks channels
• Managing critical services and parts of your infrastructure that are running in cloud or virtual environments.

Okay, so I may have drifted into too much detail again, but I hope this helps clarify why you need to dial into transaction response times as a part of your monitoring strategy.  Stay tuned for an upcoming whitepaper that will delve even deeper into how monitoring response times and other transaction analytics will help you gain visibility into the end customer experience. You can email me directly: sgorkoff@inetco.com if you wish to learn more, or receive a copy of this when we release it in March.

If you guessed transaction response times, you’re right, give yourself a point. Chances are you’re reading Bernd Harzog’s blog religiously. If you measure hop-by-hop, layer-by-layer, transaction response times tell you where the slowdown or breakdown is.

If you guessed transaction rate, you’re also right, give yourself another point. If you measure transaction rates, you know under which conditions the problem occurs and can begin to recreate it.

The third one is the hardest. You need the content of the transaction – where the error codes, status information, customer details, amounts, etc. live. The content, or the profile, of the transaction gives you the details you need to investigate root cause.

Now, hands up for who collects all this information in one place…anyone, anyone…Bueller?

And therein lies the challenge. These three pieces of information are scattered across multiple tools, teams, and systems of record. You can’t bring them all together without a lot of manual effort. Who loves war-rooms?

This is where network-based transaction monitoring tools can make a real difference. They constantly measure hop-by-hop response times at every layer (i.e. network, infrastructure, and application). They compute transaction rates. And, they correlate the two previous metrics with critical data from every transaction. In fact, they actually automate most of the problem isolation process, making it much less painful, expensive, and time-consuming.

So if you love hanging out in a tense room, with a dozen of your closest colleagues at 7pm on a Friday, eating cold pizza staring at packet traces or debug logs…carry on. If you’d like to be home with your family, with the satisfaction that you found the problem at noon and spent the afternoon breaking ground on new projects, learn more about transaction monitoring tools. The three pieces of information you need are already there.

It’s as easy as 1, 2, 3…Watch this 3 minute video on business transaction management.  Meet Marty and Sam, two IT operations managers working for (fictional) payment processing companies.  Both rely heavily on their performance monitoring tools to manage complex payments environments, but that is where their similarities end…

Click here to view the embedded video.

Moneris Solutions Shares Their Story - WATCH this webinar now!

During last week’s webinar, Kin Lee-Yow, the Director of Technology Infrastructure and Support Services for Moneris Solutions, expressed his views on how important it is to know how POS, ATM, self-service kiosks, mobile or other online banking applications are performing in the eyes of the end customer.  He shared his first-hand opinion of how without real-time transaction monitoring in place, he runs a greater risk of:

• A greater number of remote support dispatches and open problem tickets,
• Longer service disruptions and troubleshooting processes,
• More internal and third party “blame storms”, and
• Undetected performance issues affecting payment channel performance.

All things Kin mentioned above would have a negative impact on any company’s revenues, support costs and ultimately, the end customer experience.  He shared that what were once simple environments for IT and customer service teams to manage are getting more and more complex by the minute.  This is because there are multiple services being integrated within ATM and POS terminals, more EFT and interbank connections, and a higher overall volume of customer transactions being driven through these channels than ever before.  Kin also says that many tools such as network sniffers, log analyzers and switch monitoring tools were simply not designed to handle the end-to-end monitoring of a complex transaction environment, resulting in hours and hours of manual labor to piece together fragmented information gathered across many internal and third party silos.

So this is why Moneris, along with many other banks, ATM deployers, payment processors and merchant service providers, are choosing to invest in transaction monitoring as a part of their IT management strategy. 

In the past two years, we have seen business transaction management (BTM) technologies make significant progress in terms of deployment and data gathering techniques.  As a result, BTM has become the fastest growing segment of application performance management (APM) tools today.  “Traditional” BTM solutions that are expensive to deploy, tough to scale and time consuming to maintain are quickly losing ground to the alternative “lightweight” BTM approaches that have made it much easier to adopt this critical dimension of monitoring and service reliability management.

Today, BTM solutions are helping payment processors, banks, ATM deployers, retailers and merchant service providers to safely expand service offerings, streamline troubleshooting processes, and improve overall network availability.  Many BTM adopters in the payments industry are reporting at least 65% faster problem isolation when it comes to identifying issues affecting transaction performance.  In a nutshell, BTM gives these businesses the power to answer, at anytime, “How are my POS, ATM or other self-service applications performing in the eyes of my customer?” 

Some examples of what real-time transaction intelligence is telling BTM adopters about the end customer experience:

• A rise in transaction decline rates for a certain BIN range or group of POS/ATMs (ie: if one of the top 10 POS or ATMs have no transactions in the last hour)
• A rise in failed transaction rates either by POS/ATM terminal ID, card type, interbank connection, EFT connection or service application (ie: the transactions from a certain bank card are all failing)
• Response code errors that are linked to specific network or application communications (ie: a MAC or other network error occurs)
• Specific third party service response slowdowns or failures (ie: which POS/ATM service or application is having the issue, and who owns the problem?)
• Transaction trending and trafficprofile breakdowns (ie: compare transactions based on card types, on us vs. off us transactions, or profile transaction traffic originating from the various ATM services offered)

Historical transaction data can also be manipulated to discover customer trends and report on information such as:

• User frequency
• Usability issues at the self-service device
• A breakdown of traffic volumes based on services used or card type
  
• Ratio of third-party to own transactions
• Location profitability (or loss due to downtime)

For further information on how Moneris Solutions and their back-end payment processing partner, the Royal Bank of Canada, use business transaction management software to collaboratively manage end-to-end transaction performance for over 350,000 merchant locations watch the recorded version of last week’s webinar titled, “Moneris Solutions Shares Their Story:  How Transaction Monitoring Improved Visibility into the End Customer Experience.”