The ACI Universal Payments UP BASE24 Classic/BASE24-eps 2+

The ACI Universal Payments UP BASE24 Classic/BASE24-eps 2.0

What is the ACI BASE24-eps product?

Today, ACI Worldwide's UP BASE24/BASE24-eps 2.0 is 46 Years Old. That means BASE24-eps architecture is an evolving product.

Running a payments system such as UP BASE24-eps

Banks and financial institutions are highly motivated by competitive forces to broadly deploy automated teller machines (ATMs) and engage in electronic funds transfer (EFT) activities.

BASE24/BASE24-eps 2.0 is a payment engine that the financial payments industry uses.

The combination of BASE24/BASE24-eps is a competitive and attractive end-to-end retail payments solution for the finance sector.

Failure in a financial payments environment is a high-visibility customer service issue, and outages at any level have debilitating effects on customer loyalty.

The entire payments cycle must be conducted in near real-time. In such an environment, high availability is a mission-critical requirement.

Bank card processing, such as ATM, point-of-sale (POS) and credit, more than any other activity, wields an immediate and lasting impact on the reputation and image of a financial institution.

Banks and credit card companies encourage customers to use their cards, inviting them to essentially live "cashless".

As a result, the ATM and POS marketplace has undergone a rapid, expansive change in recent years.

On July 2014 data shows total cash payments were overtaken by non-cash payments. Despite a steady decline in total cash volumes it is still king with consumers, who use it for more than half of all their transactions.

The total number of cash payments made by consumers, businesses and financial organisations in the United Kingdom UK, for example, fell to 48% last year 2014 (from 52% in 2013).

To date 2021, credit debit cards accounts for nearly a huge percent of all retail non-cash payments, possible a fivefold increase in just a few years.

Growth has been sharp in both online (PIN-based) and offline (signature-based) debit.

ATM or POS processing can occur across multiple paths, either directly (through a bank's owned ATM, typically called "On Us"),

Or through one of many shared networks where the card holder is using a terminal that is owned and operated by a another entity is called "Not-On-Us" trasanctions.

An example of the cooperative networks is STAR, which is owned by First Data Corporation.

With more than 1.7 million locations across the United States, handling over 5,700 financial institutions with over 134 million cards,

STAR is just one of the many networks that are available to banks and other financial institutions that can be used to project their financial services to their customer base.

Other industry competitors in this marketplace worldwide are VisaNet, MasterCard, Pulse, NYCE, Multibanco, Interac, LINK, JCB, and others.

In total, there are more than 60 major networks worldwide available to both consumers and financial institutions.

BASE24-eps and Omni-channel

Payment engine the ACI Universal Payments UP BASE24-eps 2.0

What is Omni-channel?

Omni-channel literally means from any channel.

A channel is any payment or transactions source. From a retail banking perspective this is a teller, online, mobile, ATM, Point-of-Sale, etc.

In the past the channel and the payment engine were in one silo. For example an ATM was driven by BASE24-atm, meaning the ATM communicated directly to BASE24-atm. BASE24-atm also provided the routing and authorization logic.

This silo was not used by any other channel. POS devices communicated directly to BASE24-pos which provided the routing and authorization logic.

Any common transactions still had unique routing and authorization logic.

What makes a transfer different at a teller versus online banking versus mobile versus an ATM? At the end of the day the concept is to validate the source account has enough funds and the destination account is valid and to transfer the money.

This leads one to the concept that the channel should be separate from the payment engine.

How ATM and POS processing is accomplished

In some ways, ATM and POS processing and POS card processing are similar and follow the same transactions processing paths through the network and associated systems.

Find below the four categories of transaction ATM and POS processing can take:

  • On Us - The transaction arrives through a bank-owned ATM or POS device and is never routed outside of the bank.

    Example: A customer of the "SampleA" Credit Union uses an ATM card to withdraw money from the ATM that is located in the local credit union office.

  • Not On Us (or Network On Us) - The transaction originates from a sharing network, such as STAR or Pulse, in which both the bank and the device-owning bank are members of the same network.

    Example: A local customer travels somewhere away from home and is a member of "SampleA" Credit Union. The customer must use a device at the "SampleB" Credit Union. Both "SampleA" and "SampleB" are members of the STAR network.

  • Reciprocal Transaction - The card holder initiates a transaction at a device that is owned by a bank that is a member of a different regional network.

    In this case, a gateway is used to switch the transaction. Example: A London resident attempts to withdraw money from an ATM or POS in Edinburgh, Scotland. An agreement between the network in Scotland and the network in London England allows the transaction to be switched from one regional network to another.

  • National Bridge Transactions - The card holder uses a device at a bank that is not their own, and the two banks belong to different regional networks that do not have any agreement. Both banks must belong to the same national network.

    The transaction is handed from the ATM or POS regional network to the national network, and finally to the authorizing bank's regional network. In this case, there are three switches involved.

Transactions are routed through the originating ATM or POS, either the bank's own network or through some combination of regional or national network.

The atm pos transaction flow diagram

A high level processing flow and requirements for ATM and POS transactions.

Both the regional and national networks are switching systems that, to a fair extent, resemble the systems that are used within the financial institution.

The switching systems drive transactions from initiation to destination. We use the word "switched" to describe the hand-off of a transaction from host-to network-to host.

An ATM or POS transaction is accepted by an acquiring device that can accept cards from the issuing institution and either processed locally "On Us" or switched to one of the regional networks "Network On Us".

The networks either switch the transaction to another institution host for processing "Network On Us" or switch the transaction to a national network "National Bridge or Reciprocal".

Responses are switched from the owning host of the device, "On Us", to the device or switched to a network "Network On Us".

The network either switches a Host Response to the transaction to the host of a member bank "Network On Us" or switches the response to a another network "National Bridge or Reciprocal".

The network switches the response to another network for later switching to the card-issuer host.

Although there are other variations on this theme, transactions are switched from host-to-host through network switches until the original transaction request is completed by a transaction response or it times out.

Introduction to BASE24-eps

BASE24-eps is an integrated payment engine that is used to acquire, authenticate, route, switch, and authorize financial transactions across multiple channels.

It provides a full range of functionality to support payment transactions, both the traditional transactions that institutions manage today (for example, debit and credit at the ATM and point-of-sale or telephone banking) and emerging transactions (such as, mobile commerce and Internet banking).

The product supports all leading payment cards and offers standard interfaces to leading devices, switches, and back end host systems.

The ACI fault-tolerant application software takes advantage of the best in systems software for reliability, availability, scalability and high-performance transaction throughput.

As the major retail banking payments engine of the ACI Enterprise Payments Solutions, BASE24-eps provides flexible integration points to other applications within enterprises and integration with other ACI Enterprise Payments Solutions products.

By supporting XML and ISO-based interface standards and other industry-specific formats, BASE24-eps offers the utmost flexibility in a total, end-to-end solution.

Consumer transaction support

BASE24-eps provides comprehensive support for consumer e-payment transactions that are initiated by a variety of transaction instruments that include credit, debit, and chip cards.

As the payment industry evolves and new instruments emerge (for example, customer ID and mobile telephone numbers), the flexible nature of its architecture enables BASE24-eps to easily adapt to provide continued value.

Today in 2021, BASE24-eps supports a comprehensive cardholder and administrative transaction set that can be accessed from any appropriate delivery channel. Administrative transactions are also supported for settlement and reconciliation purposes.

BASE24-eps can be configured to maintain card and associated account information.

Authorization logic can be scripted to perform a variety of tasks that include check current status of the card, compare cardholder use against limit profiles, determine whether the transaction is allowed based on a number of configurable options and more.

In addition, BASE24-eps can provide alternate routing or stand-in authorization if a configured primary external authorizer becomes unavailable.

When BASE24-eps was architected and designed starting in 1995 a non-silo based solution was envisioned.

At the time ACI expertise was still mostly in ATM and Point-of-Sale making the first goal to provide a single payment engine that could be shared by those two channels.

Both were card based channels making this task relatively straight-forward.

The senior technical leaders could see the day that non-Card (or Customer ID based) transactions would need to be supported.

They kept this in the back of their minds as they designed BASE24-eps.

The payment processing engine transactions

Transaction switching and routing

BASE24-eps provides a highly flexible routing structure for transactions.

This flexibility not only routes transactions to the appropriate network, card association, processor or internal system for authorization, but it also helps users gain lower interchange charges by factoring in the total path when determining the authorization destination.

Determining the card issuer using a Card prefix lookup is decoupled from choosing the destination. The Card prefix lookup determines the destination profile which is then used to determine the destination along with the:

  • Source Profile
  • Destination Profile
  • Transaction Type
  • Account Type 1 (FROM account type)
  • Account Type 2 (TO account type)
  • Method of consumer authentication (PIN present, chip card, and so on)

This flexibility in transaction routing accommodates different account types that might reside on different systems and different platforms.

  • Users can customize their transaction processing at various stages in the transaction life cycle, which includes:
  • Pre-screening before transactions are sent to an external authorizer
  • Defining the processing steps for real time internal authorization
  • Defining the processing steps for stand-in authorization
  • Specifying the destination of advice messages following authorization
  • Specifying how the database should be impacted during the post-authorization process

The first step in this process was decoupling the logic to determine the issuer from the routing logic. This allows one source to route differently than another source. Routing means how to get to the issuer.

An issuer could be a back-end host system, payment network (e.g. Visa or MasterCard), or authorization provided by BASE24-eps.

The routing logic had to be robust and provide functionality for all possible channels, including alternate paths if the issuer was unavailable.

Initially the logic to determine the issuer used the prefix (up to the first 11 digits of the PAN) to determine the issuer.

The outcome of this was the Destination Route Profile which was used by the routing logic to determine how to get to the issuer.

Each source of transactions in the system was assigned a Source Route Profile allowing sources to be grouped together when the same routing logic should be used.

This would allow a different way to determine the issuer to be used without having to change the routing logic.

The next step was providing an authorization engine that was flexible enough to process transactions from both the ATM and Point-of-Sale channels along with potentially other existing channels and new channels to come.

This was accomplished by creating a script engine to orchestrate the authorization logic. Scripts could be written for each transaction type and even by channel.

Routing determined the script to execute if the transaction was authorized by BASE24-eps, either as the initial destination or an alternate destination (stand-in).

Because the input to routing was the Source Route Profile and the Destination Route Profile different scripts could be executed based on the destination as well as the source.

This allows any slight difference between the logic for a channel to be managed by the script. Now one might be thinking each script will contain quite a bit of duplicate logic; read the Card, validate the Card, verify the PIN, etc.

Shared logic is written in sub-scripts which can be shared across the scripts.

UP BASE24-eps 2.0

The next logical step for BASE24-eps was to provide a decoupling of the interfaces to the various channels and the main payment engine.

In 2012 BASE24-eps started a project to create a services based framework to create interfaces along with a set of services to be used between these new interfaces and the main engine.

Late in 2012, the acquisition of Distra required the need to reevaluate the direction of the interfaces framework.

The Universal Payments Framework (UPF) has a great UI based configuration tool to define endpoints, database entities and sessions.

UPF seemed like a logical fit to provide an interface framework. The services that were already being defined to allow the interface framework to interact with the main engine could be used to facilitate the interaction with UPF.

This became the beginnings of the Business Services Infrastructure (BSI) that could be used by C++, Java and UPF technologies.

The transaction processing codes flow diagram

Flexible authorization Processing

BASE24-eps supports consumer authentication and authorization processing using a powerful scripting engine.

Using the scripting engine organizations can control and define application logic without modifying the product source code.

Using an interpreted scripting language with syntax that is similar to JavaScript, using BASE24-eps users can create a variety of authorization scripts to tailor the authorization logic to meet specific business requirements or service agreements. Organizations can decide.

What data is used in the authorization process and when the data is used, regardless of whether the data is part of the transaction or from an alternative source. If more complex authorization modifications or extensions are required, the scripting engine also eases the introduction of a new authorization service written in C++.

The service can expose a scripted operator, referred to as an exported operator, to the scripting engines that the script can then invoke.

These services can be developed independently without affecting the rest of the system.

ACI provides a set of sample scripts that cover the basic positive, negative, or usage-based authorization processes.

This flexibility shortens the time that is needed to develop new products and services or accommodate changes that are requested by the business department of an organization.

Separating the business logic (in scripts) from the product source code also facilitates script compatibility with future releases.

Users can choose what level of authorization should be performed on BASE24-eps, which can range from full authorization using a card, limit, account and balance information, to handling pre-screening before using a host for authorization, to just providing a stand-in capability using negative card data.

All limits are user-defined to provide full flexibility in controlling the use of the cards and accounts.

Integrated consumer data

The component architecture of BASE24-eps is designed for flexibility to leverage consumer data resident in external systems and databases.

Users can develop components that expose consumer data to the scripting engine to allow more intuitive authorization functionality.

This consumer data can be held in customer relationship management (CRM) systems, fraud management systems, customer information files, core banking systems, and other applications.

By exposing more consumer information to the authorization process, organizations can improve consumer relationships by approving transactions that are based on more comprehensive consumer information.

They can also intelligently manage risk by denying transactions based on certain risk factors.

The consumer and the provider can be any technology in any combination. The code generator creates both C++ and Java code and the BSI Framework has been implemented in C++, Java and UPF.

Traditional and emerging delivery channels

In addition to support for traditional delivery channels, which includes ATM and point-of-sale (POS), BASE24-eps can process payments that are initiated through Internet shopping networks, personal digital assistants (PDAs), mobile telephones, Web ATMs, and home banking and branch systems.

BASE24-eps offers a powerful, flexible foundation for delivering common services across multiple consumer access channels, computer systems and databases.

Through XML and ISO-based interface standards and other industry-specific formats, transaction services can be exposed to any channel.

Thus, BASE24-eps can provide a single point-of-access across an enterprise for the service of consumer payments, which eliminates the costs of maintaining multiple service points

BASE24-eps is designed to be flexible in its transaction security support and to provide a range of hardware options.

The application addresses the diverse needs of large-scale transaction processing systems where the originator of a transaction might operate under an entirely different transaction security scheme than the authorizer.

Regardless of the origin or destination of payments, BASE24-eps meets the current industry requirements for security, which includes Triple DES and EMV support.

BASE24-eps operates in a network environment where sensitive data, such as the personal identification number (PIN), is secured through encryption, and the system provides cryptographic functions, such as PIN encryption, PIN verification, message authentication, chip authentication, and card verification, using interfaces to external hardware security modules (HSMs).

Intuitive Graphical User Interface GUI - The ACI desktop

The ACI desktop, BASE24-eps' user interface, employs Java, C++, and XML technologies that provide the user interfaces that are needed to manage all components of the application.

With the system's built-in user security feature, users are assigned roles that grant them permission to specific functions and tasks that are associated with various windows.

The ACI desktop Users are authenticated during the logon process, thereby minimizing the risk that is associated with unauthorized users gaining access to functions that they are not permitted to perform.

The user audit function is responsible for maintaining a secure audit database where all file maintenance transactions and modifications to the user security database are recorded.

Before and after images of the affected record are logged wherever appropriate.

The user interface design incorporates the flexibility for users to alter the layout and wording on the desktop to meet individual organization needs.

All text and positional information is maintained in configuration files, so adapting the user interface without altering the product code is particularly easy. This structure also incorporates multi-language capability.

The ACI BASE24-eps user interface presents a task-oriented view of the application for multiple users ranging from business to technical to administrative, and it incorporates graphical elements, such as hyperlinks, buttons, and pull-down menus.

GUI Users can also choose to display text labels in their local language to accommodate adaptation into their environment.

Integrated help at the window level and the field level minimizes the need for extensive user training, while streamlining business processes and providing greater flexibility.

Written in Java and C++ and using XML message formats, the ACI user interface provides a flexible operating environment that multiple ACI applications use.

A security administrator configures access permissions through the ACI user interface where a user security and user audit environment are shared by all ACI applications.

Card Scheme Compliance

BASE24-eps incorporates off-the-shelf support for a range of international card scheme interfaces that include Visa, MasterCard, American Express, and many national switch interfaces.

These interfaces are built using a framework methodology covering ISO 8583 (1987), ISO 8583 (1993), and XML standards.

This methodology makes use of "inheritance" to facilitate reusability of components and allows either ACI or the customer organization to quickly build new interfaces.

The Universal Payments platform


Now all the pieces are in place to allow BASE24-eps to be true omni-channel. UPF can be used to build out interfaces to any channel that processes card and account based transactions and send those transactions to BASE24-eps to be authorized.

UPF can also be used to orchestrate between different payment engines.

Bill payment is an example, if a card is used to fund a bill payment, the funding side of the transaction can be sent to BASE24-eps and the actual bill payment sent to the bill payment engine.

The Universal Payments platform #2

This is the beginning of the Universal Payments vision. Above is a representation of the vision, the areas in green represent where UP BASE24-eps 2.0 operates.

The journey has begun as ACI BASE24-eps is the Next Generation Payment Engine, and is twice as fast as BASE24, and is 70-90% reduction in customizations.

ACI and its customers come together to simplifying, rationalizing, cut transaction processing time by half, allowing cost of developing enhancements shared across customers and ACI continue investment in the future of BASE24-eps.

UP BASE24-eps 2.0 Training

            Contactless Card Home | About Us | Affiliate Agreement | Anti-Spam Policy | Contact Us
            Privacy Policy | Dmca Notice | Terms of Use | Link to Us