• System validates the Mandate ID details provided in the Outgoing DD transaction with Mandate ID maintained in Creditor Mandate provided in the DD outgoing transaction. In case of any exceptions, the transaction is moved to Business Override Queue.

• Debtor/Creditor/Bank/Additional details entered for a payment transaction is validated against valid characters allowed for the network. SEPA character validations are currently supported.
• If fields contain any invalid SEPA character, then the transaction is moved to Repair queue with error details.

• If ‘IBAN validation required’ flag is checked for the network, then IBAN verification for Debtor IBAN, Creditor IBAN & creditor BIC is done against the IBAN format maintained for the respective country.
• IBAN is validated based on IBAN Information maintenance (ISDESBAN) available for the country for the following parameters:
  • IBAN Length
  • Check digit of the IBAN
  • National ID of the IBAN
• If IBAN check fails transaction is moved to Repair Queue.

• Duplicate checks are done during transaction processing.
• This involves identification of duplicate transactions done for a period as maintained in Host Code level for a network and transaction type combination.
• If there are any matching transactions with the fields identical with the transaction being processed, the original transaction is identified and linked to this transaction.
• The transaction is moved to Business Override Queue for further investigation In case of a duplicate transaction.
• Duplicate transactions are listed as part of the override message for duplicate check. The override details can be viewed from BO queue.

• Sanction check for an outgoing DD transaction is done on book date & activation date in Synchronous/Asynchronous mode.
• System verifies whether sanction check system is applicable in Collections Preferences Maintenance, for outgoing transaction type and initiates sanction check validation.
• Out queue name for sending the sanction check relevant transaction details and In queue name for the response is fetched from ‘Sanction Check System’ maintenance.
• Sanction Check system provides a response for the request. This response updates transaction’s sanction check status of the payment and the response date in the sanction check master details.
• If the sanction check response status for a outgoing DD transaction is ‘Approved’, then further processing continues.
• If the transaction’s sanction check response status is ’Interim’ or ’Rejected’ or ‘Timed Out’, then transaction is logged in ‘Sanction Check Exception Queue. Processing of the transaction is stopped at this stage.
• If sanction check is not required at Network preferences, then the payment’s sanction check status remains as Not applicable and no information is placed in the sanction check queue.

• Charge and tax for outgoing DD transaction is calculated based on the Pricing Code linked to Network DD preferences.

  Note:

  Charge computation at this stage is applicable for transaction received from SOAP/REST web services. Charges for transactions entered from UI screen is computed during enrichment/save.
• Pricing components applicable to the price code and the attributes like whether the component is a charge or tax, Pricing currency and the exchange rate type are derived from Pricing Code maintenance (PPDCDMNT).
• System derives the debit customer from ECA-CIF Account Mapping maintenance.
• Customer service model linked to the customer is obtained from Service model.
• Customer Linkage maintenance (PMDCSMLK)
• Charge components are processed prior to tax components involved.
• Tax amount is computed based on component value which is linked as basis element in price code. Tax rate is applied on the charge amount calculated. If charge currency and tax currency are different, then charge amount which is the basis for tax is converted in tax currency using mid rate of the exchange rate type linked to the tax component.
• If waiver flag is checked for a charge component, component charge amount is still calculated. This amount is further awaited and cannot be recovered from debit account.
• If a charge component is waived, the related tax gets calculated. Application of this tax is based on the waiver flag at tax component level.
• Customer debit amount for charge/ tax is computed based on the credit account currency involved. If charge/tax currency is different from credit account currency, then currency conversion is done using mid-rate of the exchange rate type linked to the component.
• Component wise charge/tax currency, amount, debit currency, debit amount and waiver flag value is stored for the transaction.

• Once processed, system populates the Outgoing DD transaction data for pacs.003 generation.
• Support is available for bulk dispatch of pacs.003 message in EBA IDF file format to an Direct participant bank code (if processing branch is an indirect participant) or to CSM directly (if the processing bank is a direct SEPA participant).
• Once the message is dispatched, the corresponding transactions in the file is updated with transaction status as ‘Active’ and Collection status as ‘Outstanding’.
• Consolidated credit amount is computed based on the transactions sent in same dispatch file.
• System creates multiple bulks based on the value date (Interbank settlement date) in a single IDF file.
• Dispatch accounting entries is triggered based on every message id and dispatch reference no combination with dispatch accounting code.

• For a transaction, tracking is based on both Dispatch Reference and File Reference so that when a file re-generation is triggered only the transactions which were part of the original file only should be picked up.
• Dispatch file generation is based on the activation date. If the activation date is a network holiday, dispatch will be scheduled for first cycle of next network business day.
• Settlement date population for the bulks is based on the instruction date of the transaction. The dispatch file has separate bulks based on settlement date if future dated transactions are part of the file.
• If any transaction is with back value instruction date, the settlement date is populated as current date provided it is not a Network holiday or to next network business day.
• On force release from Network Cutoff queue, if no dispatch cycle available for current date, a new dispatch schedule is created without populating the time. This transaction can be either manually dispatched on the same day or the next day’s first dispatch cycle will pick up the transaction.
• Dispatch accounting consolidation has to be based on settlement date, transaction branch and message type.

• Batch processing support is available for STEP2 SDD service.

• Instructed Agent is stored for each transaction with the batch booking preference.
• The Input Debit File may contain multiple batches. The number is set by the bank, but is subject to a maximum threshold. Each batch contains the same:
  • Message Type
  • Interbank Settlement Date
  • Instructed Agent / Assignee

STEP2 network file names structures are as follows:

• EEVVSSSBBBBBBBBX…X.Z
• EE must be S2 (STEP2);
• VV is the format version, that is set as follows for the SDD Batch Processing Mode:
  • “03” must be used by Participant to send IDF Batch Processing file to STEP2 MPEDD
  • “02” must be used by Participant to send IDF Bulk Processing file to STEP2 MPEDD
• SSS is the three character service identifier, “COR” for Core and “B2B” for B2B;
• BBBBBBBB is the BIC(8) of the Direct Participant;
• X…X (optional) is up to 15 characters for use by the Direct Participant.

• Notifications would be sent on below scenarios and viewed from PMSNOTFY screen.
• Collections liquidation
• Collections cancel from any exception queues
• Collections value date carry forward

• BOD batch job of DD picks all the outgoing DD transactions with Collection status as ‘Pending’ and Value date as current application date and post the debit/credit liquidation entries.
• Accounting details are handed off to accounting system with debit/credit liquidation accounting code linked at Network DD preferences.