In the case of Payment, ATM and POS (TLF and PTLF) transaction querying and archiving, the amount of data that can be stored and queried is only limited by the number / capacity of hard drives configured to store the transaction data (for instance, a key major bank stores 12 months of POS transaction data with RTLX Reactor).
The Saudi National Switch (SAMA - Saudi Arabian Monetary Agency) has recently mandated that all banks must accept and handle customer complaints and disputes on transactions executed anytime since the switch was commissioned back in 1990, hence the need for enhancing accessibility to this magnitude of transaction records in RTLX Reactor.
Transactions archive and query browser screenshots: a, b and c.
Transaction data fields stored in RTLX, can also be encrypted, masked or omitted in line with PCI DSS directives as appropriate.
RTLX Reactor can archive payment transaction log files and from version 5 onwards of BASE24 Classic. From version 5, the structure of the TLF and PTLF log files is fixed with only new data (token data) appended to the end of each record. As such, the RTLX extraction client can parse each record for the component header and authorisation fields and insert them into a standard format Microsoft SQL or Oracle database for querying and archiving.
As such RTLX Reactor can, out-of-the-box archive transaction payment data to a Windows Server. The number of years it can archive transaction data for will depend on when the bank first started to use version 5 of BASE24 Classic. For other payment platforms, a lean, optimised payment extraction client can be developed as a plug-in to RTLX to ptovide the same browser visuals.
For BASE24, any transaction data before version 5 will require ITL to look at each file and the given DDL Schema format for that file for each successive upgrade of BASE24 up to version 5. This may require successive changes to the HP NonStop RTLX extraction clients so that they can make sense of the transaction data. The transaction data will then be parsed into the existing standard database format were possible.
As such, RTLX Reactor may be able to go back say 8 years automatically out-of-the-box (depending when the bank started using version 5) and then require code changes to account for pre-version 5 TLF and PTLF log files.
ITL can supply more information here as required by the bank.
ITL can provide a product quote for any version 5+ automatic extraction of BASE24 transaction data (plus implementation and storage requirements etc.). After that, each pre-version 5 POS and ATM file will need to be analysed by ITL and a separate quote provided for pre-version 5 extraction of POS and ATM data.
Data maybe queried by different departments inside the bank as well as other banks’ customers using this bank’s network in dealing with customer queries, disputes and/ or complaints, in compliance with given mandates, e.g. SAMA.
The current solution provides browser querying of the transaction data.
Payment and Transaction Query Screen
· The TLF and PTLF ENSCRIBE files on the HP NonStop platform have only a few alternate keys to query on via a supplied green screen. In RTLX transaction analyzer, the query screens allow ALL transaction fields (200-400 fields) to be queried and compared in a single query with no SQL programming knowledge required
· Authorised users can be given a controlled subset of fields to query on or all fields depending on their status, e.g. Administrator, payment platform technician or junior so that more sensitive field values are restricted, for example card number
· Often used queries can be saved and reissued at a later time without the need to remember the transaction fields involved. HP NonStop ENFORMs for the same task are not always documented and sometimes lost over time
· HP NonStop ENFORMS can take hours and days to construct by experienced technicians (who often have more important tasks assigned) long after the issue or problem has occurred. The RTLX queries are built in seconds and minutes and can be changed easily and stored at a click
· Saved queries provide a ‘Knowledge Base’ for quick troubleshooting of fraud or customer queries. This is useful when key HP NonStop staff move on and their payment application, ENFORM or BASE24™ problem solving skills are lost
· EMS (Event Management Subsystem) alerts and their mandatory token fields can also be accessed via the RTLX query screens
· Results returned from payment, (P)TLF and EMS queries can be saved in Comma Separated format (CSV) to use in spreadsheets or for emailing purposes
· Query results returned can be ordered by simply clicking the column headings and number of results per page can be adjusted
· Transaction data on the Windows server can be queried long after payment log, HP NonStop TLF and PTLF ENSCRIBE transaction log files have been archived off to an IBM mainframe or storage media. Customer complaints can be investigated and resolved more quickly where currently, backups may need to be restored which may take a number of days
· Complex queries can be formed via the simple to use browser interface and issued against the Windows SQL Server database. This means that no precious CPU cycles are taken up on the Live or Standby HP NonStop systems
· Fraudulent transactions and patterns can be spotted by querying on specific fields with the transaction logs not previously available for keying. For example, a specific card in a certain part of the country at the same ATM or POS device for the same or lessening amounts.
· Query views are concurrently accessible as for all the views in RTLX transaction analyser and can be secured
PCI DSS (Payment Card Industry Data Security Standard) compliance is provided by the native facilities of the Microsoft SQL Server product (Master key, Certificates, Symmetric key, EncryptByKey, DecryptByKey using AES_256, Triple DES etc.) which is the database manager for the Sentra and RTLX environments as well as encryption (including column level encryption), masking and/or blanking of field values by Sentra, e.g. PAN numbers.
Data can be encrypted and compressed if required, as it is relayed from the HP NonStop, Windows and Unix platforms.
The real-time payment transaction visuals and data presented to the user are based on the authorisation level of that user as set-up in RTLX. Further modifications can be automatically applied to data stored in the SQL database such as X’ing out (or blanking out) card numbers, e.g. XXXX-XXXX-XXXX-2207.
RTLX includes a multi-tier security model for users whereby groups are configured to access one or more functions within the product and then users are allocated to one or more RTLX groups. So for example, a user might only gain access to the MI reports group or the payment querying group or both. If they are allocated to a group, they may still be restricted from using certain functions such as restricted query access on the payment querying screen.
Though users may gain a secured level of access to the RTLX product, they of course will not be able to access the MS SQL database directly.
In order for ITL to install RTLX Reactor at one of the UK’s largest banks, strict security directives needed to be adhered to and a separate document relating to security considerations is part of the RTLX product evaluation delivery.
Also, since BASE24 XPNET does not have an audit log, RTLX Reactor is able to monitor the EMS logs for XPNET security violations and escalate potential security threats. Management Information reports can then be produced, e.g. end of day or cut off period.
RTLX Reactor Transaction Analyser - Performance
RTLX Reactor is able to achieve between 1200 and 3000 transactions per second for real-time (or batch) monitoring of your Live or Contingency payment platform or HP NonStop BASE24™ application(s), either POS, ATM or BOTH.
The parameters needed by the extraction client are configured and stored in the Sentra Windows server database and downloaded to the HP NonStop node where they are held in local parameter files, one per (P)TLF extraction client. The parameters can be split into the following types ;
• Log file placement.
• Restart details.
• Data Formatting.
• Performance.
The ‘log file placement’ parameters detail the location of the payment log, TLF and PTLF files. The log file to be tracked can be created directly by the primary payment application or it can be a copy created by one of the database replication tools available in the HP NonStop arena. If available, the latter option may alleviate some of the file contention issues placed on the core application.
The log file name will be a generic file name, e.g. $DISC.SUBVOL.TF, and the suffix will map on to a processing date in the format, YYMMDD. The extraction client will recognise when the log file has been rolled and it will close redundant files and automatically track the latest log information held in ‘today’s’ new file.
The ‘restart parameters’ are used to allow the extraction client to reconnect to the TLF or PTLF file at the last known point of processing.
This capability will be used following either a planned or unplanned payment platform, BASE24™ or Sentra outage. A control file, one per extraction client, will be updated with details of the file name being processed, the timestamp of the last record read, and positioning information for that record. This combination of information will allow the extraction client to identify and read an exact record without the need for a sequential read of the entire file.
The ‘data formatting’ parameters are used to suppress the transmission of certain parts of the payment, PTLF and TLF data. This will help to reduce network and processing workloads.
For each individual extraction client, there are also a range of configuration options that allow further lower level tuning.
Each extraction client can have a process name, CPU location and process priority allocated to it. With this flexibility at their disposal, users can fit the RTLX processing into their existing capacity planning model, and allow processes to execute efficiently in relation to the location of the BASE24™ application and its log files. By default the extraction client will read and process a record as it is added to the end of a log file. However, there are three further options that will allow users to reduce the file processing when required.
• One or more extraction clients can be closed down from the central Sentra ‘Program Control’ screen. A subsequent restart will see the client reconnect to the log file at the last point of processing and read forward. This is a manual operation and it is used most often during planned system outages, but it could be used during intensive processing periods if required.
• Users can create a calendar parameter, which will allow the extraction client to sleep at busy times of the day. If this value was set to 12:00-13:30, for example, then the Sentra software would not access the logging files during this 90 minute period, and it would then resume processing from the last known point. A maximum of 5 calendar values per 24 hour period are allowed. This is an automatic feature.
• Finally, users can specify a transaction rate. This equates to the maximum number of records that will be read from the log files per minute. This parameter will allow users to throttle the amount of activity on the log files and to spread the processing curve over a 24 hour period. This is also an automatic feature.
Although one of the major benefits of the Sentra processing is to track the payment log, TLF and PTLF files in real time, it is possible to execute the extraction client in batch mode so that it processes the content of a log file once it has been rolled at the end of a processing day. The final configuration option is to choose the data that will be dispatched to the central database for analysis.
Insider Technologies Limited (ITL) deliver a Windows Dynamic Linked Library (DLL) file for each installation / bank. This contains a description of each token type to be extracted as specified by the bank. These can be standard or customer tailored tokens.
In order for the RTLX Reactor product to extract each TLF (ATM) and/or PTLF (POS) token from the trailing end of each file record, the format of each (standard or tailored token) needs to be specified to ITL. Many standard BASE24 tokens are already extracted and stored by the product.
Transaction log file records. Transaction log files provide information about each transaction processed by the BASE24 system. The processes that create log file records can include tokens in the information logged to the files. The tokens logged to the transaction log files are configurable using the TKN file maintained using the BASE24 product screens. Log files contain historical records for completed transactions. The information in the file is, in general, not used for further authorization processing. By logging tokens to the log file, the token information is available for perusal, for reporting, and, using extract, for host processing. The tokens written to the log files are specified using the Token File (TKN).
For many tokens, 2 data structures are defined – an ASCII format and a binary format. The binary format is used in the internal BASE24 message and when tokens are written to BASE24 files. The ASCII format is used for tokens in the external message.
The RTLX Reactor product is compatible with K, S, Itanium or Integrity Blade NonStop nodes on either Live or Standby platforms. The RTLX extractor clients can access either Live or DR transaction log files (or both for contingency relay of transaction data to 2 Windows Servers) depending on your preferred configuration.
RTLX Reactor relays data over NonStop TCP/IP (v4 or v6) using the ITL FastPipe product which is part of the standard deliverable.
Minimum Windows Hardware Requirements
Contact ITL if you would like to use an Oracle database implementation of RTLX Reactor.
For optimum performance, it is recommended that the minimum specification of your hardware and software is as follows :
- 2 x (separate Application and Database servers for optimum performance) Windows Server 2000 / 2003 / 2008 (2008 - 64 Bit Version) with the latest service packs
- Microsoft SQL Server 2005 / 2008 (2008 - 64 Bit Version) with the latest service packs and Microsoft Reporting Services if required
- Either; Tomcat, IBM WebSphere, JBoss (formerly BEA WebLogic) web application servers (ask ITL about MS Internet Information Services- IIS) - also requires Java SE version 6+ (1.6)
- Browsers; Internet Explorer (IE) ver. 7+, Google Chrome, Safari, Firefox
- Mid to High-End, Multi-Core Intel Processor
- 32+ GB RAM recommended
- SCSI interface (SCSI2 Ultra-Wide recommended)
- 10 GB Single Drive for operating system and SQL Server software
- * 1 Terabyte Single Drive for the SQL server RTLX database (RAID 0+1 recommended) - NOTE: see below for drive storage size considerations for multiple years of ATM / POS transaction data querying / archiving
- 20 GB Single Drive for the SQL server log file (RAID 0+1 recommended)
- A Network Card (at least 100Mbps) is required
- Graphics resolution 1024 x 768 recommended
- 17" or larger colour monitor is also recommended
*The size of the hard drive will depend on how many months worth of data you wish to store for comparative analysis, or you may wish to use a SAN. Using standard daily file sizes for payment log, TLF and PTLF, a 1 Terabyte drive provides 2-3 months worth of storage. BASE24 (P)TLF token extraction requires further storage.
An archiving facility will be required should payment logs, TLF and PTLF data need to be stored when the hard drive gets close to maximum capacity.
The above specification is for guidance only. The specification of your MS Windows Server will be dependent on your individual needs and discussions with your MS hardware / software supplier. Please contact the Insider Technologies Helpdesk for more information.
SQL Server Versions Supported by Sentra (also install Microsoft SQL Reporting Services)
The Sentra database is compatible with the following variants of SQL Server :
- 2005 / 2008 Standard Edition
- 2005 / 2008 Enterprise Edition
- 2005 / 2008 Developer Edition*
- 2005 / 2008 Express – the default installation on the CD uses SQL Express with Advanced services, so that SQL Reporting Services is available
* Some SQL editions include a concurrent workload governor. Performance degrades when more than five queries are executed concurrently. Sentra will work with these versions of SQL Server but performance may be unacceptably slow and its installation is not recommended for high volume usage.
SQL Express editions support databases with a limited maximum size (4 GB for SQL Express 2005). Users who anticipate large database storage requirements should consider installing the Enterprise edition of Microsoft SQL Server, or contact Insider Technologies for advice.