Transaction Switching and Routing - In BASE24-eps

 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