Sterling B2B Integrator - Managing EBICS Transactions

Transaction Manager in the EBICS Server is responsible for maintaining the transaction states. It determines the segment that is required to generate the XML response message.

Transaction Manager handles the upload and download transaction flows and supports segmentation and recovery of order data.

Upload From a Subscriber (FUL)

The FUL order type is used to upload data to a bank.

The upload transaction comprises the following phases:

  • Initialization
  • Data Transfer

The user sends the upload (FUL) request to the bank. FUL is a bank-technical upload order type.

Important: For large FUL payloads, the Maximum Idle Time (MaxIdleTime) setting in the EBICS Server Service should be increased. If the MaxIdleTime setting is too low, the transaction could be cancelled before it completes. An appropriate setting for large FUL payloads is 300 minutes.
 

The EBICS Order Authorization service handles incoming order requests for the bank-technical upload order type. If an order has obtained the number of signatures required, this service forwards the order to the subscriber upload mailbox. Otherwise, this service retains the order data in the database until all the required number of signatures is obtained.

The handleEBICSRequest business process receives a user’s request. If the user’s request contains the last segment of the order data, it invokes the EBICSOrderAuthorizationProcessing business process asynchronously to unpack the order data and generate the following files:

Note: Unpacking order data includes decoding, decrypting, and decompressing the order data.
 
  • .DAT – Contains the unpacked order data in a user’s upload mailbox
  • .SIG – Contains the signature of the order data in a user’s upload mailbox
  • .PRM – Contains the order parameters in the user’s upload mailbox
  • .PSR – Contains a status report of asynchronous processing in the user’s download mailbox
Processing Initialization

A user initiates a transaction by submitting the requests containing information about the incoming order. Based on this information, the EBICS Server verifies the order type, performs the message replay test, verifies message authentication, and checks user authorization before accepting the request.

After successful verification of the order data, the bank generates a transaction ID and includes the ID in its response to the user.

Processing Data Transfer

When more than one segment is required to transfer order data, the bank performs message authentication, verifies the transaction, verifies the segment number and size. After the EBICS Server receives the last segment of the order data, the complete order data is forwarded to the EBICSOrderAuthorizationProcessing business process asynchronously and the transaction ends.

The EBICSOrderAuthorizationProcessing business process unpacks the order data and forwards it to the user upload mailbox. The EBICSOrderAuthorizationProcessing business process generates post processing report (PSR) and routes it to the user’s download mailbox. This business process also generates the .SIG and .PRM files to be forwarded to the user’s upload mailbox. An .err file is generated when EBICSOrderAuthorizationProcessing business process encounters an error, for example, an invalid electronic signature. Use the .err file to inspect an invalid order data file, if necessary.

Download From EBICS Server (FDL)

The FDL order type is used to download data from a bank.

The download transaction comprises the following phases:

  • Initialization
  • Data Transfer
  • Acknowledgement

A user submits the FDL order type to the bank. The user requests the download of the .PSR report to get the status of the FUL request. The user can also request to download valid file formats other than .PSR by using the FDL order type.

Important: For large FDL payloads, the Maximum Idle Time (MaxIdleTime) setting in the EBICS Server Service should be increased. If this setting is too low, the transaction could be cancelled before it completes. An appropriate setting for large FDL payloads is 300 minutes.
 
Processing Initialization

The bank verifies the message from the user. After the bank verifies the user’s request, the bank collects the order data from the user’s download mailbox based on the file format information in the request.

If more than one message matches the file format, the bank joins the contents of each message into a single order data and invokes the order data processor synchronously to pack the order data.

If the encoded form of the order data exceeds 1 MB, the order data is separated into segments. The first segment of the order data and the transaction ID is included in the response to the user.

Processing Data Transfer

The user sends the request for the next data segment. The bank authenticates the message, verifies the transaction, and the segment number and size.

In each transfer phase, the bank transfers all the segments until the last segment of the order data is included in its response to the user.

Processing Data Acknowledgement

After receiving the last segment of the order data from the bank, the user initiates the last phase, the acknowledgement request, to indicate that the data transfer has been successful.

If the bank receives a positive acknowledgement (receipt code=0) from the user, the bank moves the downloaded messages from the user download mailbox to the user archive mailbox. If the bank receives a negative acknowledgement from the user, the bank retains the downloaded messages in the user’s download mailbox.

If a user wants to download valid file formats other than the .PSR reports from the user’s archive mailbox, the user must specify a date range in the EBICS request. The user must ensure that the date range matches the drop date of the .DAT file when moved from the user’s download mailbox to the user’s archive mailbox.

Segmentation and Recovery

EBICS Banking Server is responsible for combining all these segments to reinstate the order data to its original form.

The order data request (upload or download) cannot exceed 1 MB in compressed, encrypted, base64 encoded form. If the order data request exceeds 1 MB, the encoded form must be separated into segments.

If an error occurs during the delivery of the order data segments, recovery can be performed. The user can download or upload the appropriate segment according to the recovery point sent in response by the server.

Recovery allows the transmission of an order to continue despite the occurrence of an error, without necessitating the retransmission of all order data segments that have been transmitted successfully.

A recovery point can be used to continue transactions from the transaction step that follows this recovery point in the transaction step sequence. Recovery points must be set during the recovery process:
  • For upload transactions, the recovery point is the last transaction step wherein the bank has successfully received the request message and transmitted a response to the user. The recovery point is determined by the state of the transaction in the bank system.
  • For download transactions, several recovery points may exist. All the previous transaction steps of the transaction wherein the bank has successfully received the request message and transmitted a response to the user.

VEU Processing

EBICS Banking Server supports the Distributed Electronic Signature (VEU), which allows multiple partners (or subscribers) to authorize an order.

VEU is a German abbreviation meaning Distributed Electronic Signature. With VEU, multiple partners(or subscribers) can authorize an order. Different partners from different customers or the same customer can sign a particular order. Partners can request their orders that have pending signatures and sign or cancel them. The VEU management system in EBICS Banking Server saves the orders for which signatures are pending from different partners until one of the following occurs:
  • The necessary number of authorized signatures have been received.
  • The order is canceled.
VEU uses the following order types:
  • HVU
  • HVD
  • HVZ
  • HVE
  • HVS
  • HVT (Optional)

Authorized signatories of a customer can use different signature processes which may support different hash processes resulting in different hash values. In the VEU process, the hash value of the order data is provided when the order types HVD and HVZ are executed. This hash value is derived from the signature version used by the subscriber executing HVZ and HVD. The hash value is provided with the signature version used as an attribute.

Here is a summary of the typical VEU process:
  1. An EBICS Customer (PartnerA) initiates an order by transmitting the order data in an EBICS transaction with the order attribute OZHNN and signing with signature class E, or T.
  2. When received by the EBICS Banking Server, the VEU management system analyzes the order type and signatures that have already been submitted, including their class. If further signatures are necessary for processing of the order, it is stored intermediately for the VEU process together with its hash value.
  3. Another EBICS customer (Partner B) who has a pending signature and needs to sign a stored order will inquire using order type HVU or HVZ to find out which orders they are authorized to sign. The response includes information about the:
    • order type
    • order number
    • number of signatures required and number already provided (including whether their own signature is still required or has already been provided)
    • original order party
    • size of the uncompressed order data
    • (Order type HVZ only) hash value of the order data
    If order type HVZ was used, skip the next step.
  4. Partner B uses order type HVD to check the order and get the hash value of that order.
  5. Optional. If order type HVT is supported by the bank, Partner B can download additional order details using order type HVT. Depending on the request parameters, they receive either information on the individual order transactions (account data, amount information, processing date, utilization data and other descriptions) or the complete order data.
  6. When all required information is received, Partner B can sign the order using order type HVE. The VEU management system in EBICS Banking Server validates and adds the signature to the order.
  7. Partner B could choose to cancel the order using order type HVS.
  8. When all signatures are completed, EBICS Banking Server will completely process the order.

Previous Topic

Managing Subscription Manager Information

Parent Topic

Sterling B2B Integrator - EBICS Server Concepts

Next Topic

Managing Keys

Browse Categories

Share Blog Post

Pragma Edge (4.5/5)
4.5/5
Source: IBM

Recent Blog Posts - Read More

At Pragma Edge, we are a forward-thinking technology services provider dedicated to driving innovation and transformation across industries.

  • 12926 Gran Bay Pkwy W., Suite 220,
    Jacksonville, FL 32258
  • info@pragmaedge.com
  • +1 (848) - 999 - 9090
Linkedin Facebook-f X-twitter Youtube Instagram

What We Do

Industries

Products

Who We Are

Sterling Data Exchange

Thank you for submitting your details.

For more information, Download the PDF.

Get Solution Brief

PragmaEdge Universe | 2024

Thank you for the Registration Request, Our team will confirm your request shortly.

Invite and share the event with your colleagues 

Return to home page

IBM Partner Engagement Manager Standard

IBM Partner Engagement Manager Standard is the right solution
addressing the following business challenges

IBM Partner Engagement Manager Standard

IBM Partner Engagement Manager Standard is the right solution
addressing the following business challenges

IBM Partner Engagement Manager Standard

IBM Partner Engagement Manager Standard is the right solution
addressing the following business challenges

Pragma Edge - API Connect