Introduction to Temenos Payments

Temenos Payments is an enterprise payment hub solution that provides the bank with a single solution to configure different payment types without any software changes. The payment management features enable the users to prioritise and specify date execution, override changes manually, and manage service level agreements through parameterisation.

It is designed to maximise Straight-Through Processing (STP) to configure automated actions for exceptions and minimise manual interventions to reduce risk and improve efficiency. It can also eliminate redundancies and help in consolidation of different payment systems in a single solution. This is performed when the solution is deployed as follows:

  • ‘Embedded’ with Temenos Core Banking
  • ‘Standalone’ with an external DDA or accounts system

This section is designed to help the Temenos Transact users to understand the application features, navigation and functionalities related to the Temenos Payments module in Temenos Transact. The user can process all payment types in a single system by using the following features:

  • Receive, process, and send cheque requests between same or different banks
  • Add a code word to the payment message to convey processing information that can help the financial institution
  • Execute dynamic routing between different payment types
  • Maximise STP by using automated exception handling
  • Handle large volumes of payment requests or transactions
  • Process instant payments with 24/7 processing and real time connectivity to clearing
  • Screen a payment before processing to monitor and control risk
  • Debit an account on regular basis based on the requirement
  • Support cross-border payments that involves fund transfer between customers and banks in different countries with different currencies
  • Allow manual intervention to continue the process of payment
  • Define a charge type based on the customer to apply on different transactions
  • Check an account for sufficient funds to perform a debit posting
  • Schedule future payments in advance
  • Transfer different or same currency between accounts within the bank
  • Investigate the status of the payment and generate a report
  • Identify a channel to send the payment to its customer

Temenos Payments is the central payment processing engine of the Temenos Payments suite that converges and processes all payments. It is designed as a back-office application, which receives payments simultaneously from multiple channels and processes them parallelly in large quantities in Straight-Through Processing (STP) mode. Payments can be initiated from the banks’ front office applications (such as branch systems) and back-office applications (such as Treasury, external clearings and settlement systems). Temenos Payments is a multi-company, multi-currency and multi-lingual system built for enterprise wide use by global banks. It processes the following:

  • Single and batch-based payments
  • Domestic and international payments
  • Variety of payment instruments

Additionally, it comprises of the following:

  • Scalable STP engine
  • Payment processing workflows
  • Workflow orchestration manager to create and amend processing workflows
  • Business rules that define the characteristics of processing
  • Generic payment object with attributes that span universal messaging standards
  • Functional components to process different types of payments, with a set of configurable parameters that allow simple plug-and-play operation for an elaborate set of payment products and processing capabilities
  • Manual action screens to repair payments that fail STP processing
  • User interface for full-fledged support for R-processing and exception handing of payments (such as, reject, return, refund, and recall)
  • User interface to create payments orders
  • Intuitive monitoring dashboards and enquiries for effective management of the whole enterprise
  • User accessible security and user agent-based definition
  • Technical framework to configure new clearing systems and message mapping works using XSLT transformations
  • Interfaces to bank host systems and clearing gateways

This processes the request (automatically) end-to-end within the payments processor using a set of pre-defined static data configurations and business rules. If the payment destination is external (to an entity outside the bank), it distributes the payment outward. If the payment cannot be processed automatically due to errors, it moves the payments to manual processing (by dedicated users in operation roles).

Temenos Payments interacts with various banking systems that require an external interaction to supplement payment processing. It parks the payment in ‘Waiting’ queues within the processor for an external interaction. The payments processing resumes automatically when it receives a response.

System Context

Temenos Payments processes the payments in association with a set of bank host systems that are part of the suite:




Path through which the message reaches Temenos Payments

Clearing and Settlement

Determines the channel through which an outgoing or redirected payment is sent to the intended customer

Sanction Screening

Offers watchlist screening, and a range of intelligent and flexible fraud checking modules to ensure highest detection rates at lowest costs

Payments Repair

Conducts payment transactions electronically without the need to re-enter or manual interventions

Liquidity Manager

Provides mechanisms to set business rules and processes, which allows the bank to implement strategies to satisfy its payment obligations


Receives payment data published by Temenos Payments and generates analytical reports

Core Banking

Performs account authorisation (validation, funds check and reservation) and posting (debit and credit posting)

General Ledger

Receives general ledger bookings generated as part of payment processing

Mandate Management

Validates mandates associated with a direct debit, amends an existing mandate or registers new mandates

Data Warehousing and Reporting

Extracts payments data for data warehousing and MIS reporting

Temenos Payments is installed as a standalone product or an embedded module with Transact and Temenos core banking system. When it operates as a core banking system, all interactions with Transact are through internal interfaces, which offer faster turnaround times as all interfaces are supported out-of-the-box.

Key Functions

Temenos Payments performs the following important payment functions:



Payment Order Manager (Front Office)

Allows bank users to manually input or electronically collate payment order capture and enquiries from various online channels using APIs or messages.

Performs preliminary validations, such as, BIC validation, IBAN validation, clearing reachability check, funds check and fraud check. Sends the accepted orders to bank’s payment system for further processing. It also allows capture of single payments or bulk payments.

NOTE: This feature is available as a standalone module.

To know more, refer to Payment Initiation.

Payment Product

Allows banks to define payment processing products that cater to various business needs of banks (corresponding to business products in real world). It enables to configure various processing capabilities and characteristics in the payment workflow.

Products can be defined based on following payment characteristics:

  • Type of transfer (customer, bank, domestic or international)
  • Payment direction
  • Message priority
  • Single
  • Batch
  • Source of payment
  • Payment amount currency
  • Amount
  • Charge type
  • Code words
  • Various other payment attributes


Allows to set bank (correspondent bank) or client specific agreements and conditions as follows:

  • Bank Conditions – Defines the way the payment engine processes a payment for a correspondent bank. It influences STP processing of the payment and allows to customise banks’ charge account, payment warehousing, statements and advices.
  • Client Conditions – Allows the customer to choose their preferences from a pre-defined set of possible options. This provides customer flexibility to define their choices beforehand and agree to the services being availed from the bank. This helps the bank to profit from marketing and increased awareness among clients about their service offerings.

Routing and Settlement

Determines the routing channel and settlement account by configuring business rules based on payment attributes.

The routing channel can be a ledger (in-house), clearing house or RTGS, bilateral participant bank, preferred correspondent, or SSI correspondent through SWIFT.


Supports various clearing schemes including RTGS, ACH and Instant. It allows the bank to configure and use clearings in plug-and-play model, with extensive capabilities for message transformations and clearing gateway interfaces.

Clearing Directory and Reachability

Allows upload and management of clearing directory file received from clearings, and performs reachability check during payment processing.

NOTE: Each clearing directory has a separate license.


Allows the bank customer to schedule future dated payments. These payments are held in Temenos Payments, as the customer has requested for future date. The user can cancel the payment, amended or force released manually while in warehouse.

Business Dates

Calculates various business dates of a payment (such as value, execution, debit, payment send date) that are necessary to process the payment. The calculation varies based on characteristics and attribute of the payment.

Temenos Payments provides banks with a provision for custom development that can influence the date calculation for local requirements.

Fees and Billing

Provides comprehensive and flexible fee definition functionality. It supports the following:

  • Definition of fees for clients and correspondent banks
  • Different calculation methods based on percentage and flat fees
  • Fees based on amount bands, conditional and unconditional fee definitions
  • Minimum and maximum banding
  • Ability (for an operator) to impose fee that overrides fee configured in the system
  • Fee functionality for external billing purpose

Forex (FX)

Supports cross-currency payments. Foreign Exchange (FX) rates are fetched or configured from:

  • Standard FX rate of the bank
  • Payment sent to Treasury department for special rates based on payment attributes.

Temenos Payments supports rate fixing and customer specific FX discounts.

Sanction Screening

Sends payment information to sanction screening system for screening against OFAC or other screening lists.

When operating with Temenos screen as the screening engine, Temenos Payments offers extended functionalities (including a standard out-of-the-box interface).

Investigations and Enquiries

Performs investigations on payments based on queries from customer or internal banking departments. It provides a set of enquiries and audit trails that helps users to investigate and report on status and reason for errors.

Funds Reservation

Performs funds reservation based on transaction amount (or amount plus charges) by interfacing with bank’s core banking system. If the funds are insufficient, it allows to perform the following:

  • Manually authorise the payments
  • Automatically retry reservation at defined intervals.

NOTE: Temenos Payments can also skip reservation when a fund is pre-authorised for a payment.


Supports R-processing functions for payments (such as reject, return, reversal, refund and recall). It provides necessary pages for handling manual exception and processing workflow to process R-transactions.

Status Reporting

Generates debit or credit advice, payment confirmation notifications and alerts (as an SMS, e-mail, messages, fax) to customers on their payment order status.

Monitoring Dashboard

Provides an enterprise wide dashboard for monitoring the payments that Temenos Payments processes.

Agency Banking

Supports the bank to run agency banking service, and acts as an intermediary or correspondent to indirect participants in a clearing.

Direct Debits

Supports Direct Debit (DD) payments processing. IT also allows mandate validation and storage (if required) for DD processing.

Cheques and Drafts

Receives and processes cheques and drafts deposit requests, and supports inward and outward collection process.

Workflow Management

Allows to build, amend and maintain payment processing workflows.

Bulk Payments

Processes bulk files that are sent by corporate clients. The bulks are processed in-house or through a clearing using respective scheme guidelines. Temenos Payments also allows bulk file upload and manual capture functions for SME and corporate clients.

Manual Payment Capture

Provides a comprehensive set of payment capture options specifically designed for mid and back office requirements.


Performs debit and credit posting by interfacing with bank’s core banking system.


Supports users and user agents, roles and rights configuration, and user authentications.

Payment Instruments

The different payment instruments available in Temenos Payments are as follows:

Payment Instrument


Credit Transfers (CT)

Initiating party is credited by the originating bank and a credit is passed to the counterparty bank where beneficiary party is held.

Temenos Payments supports full life cycle of all available types of credit transfers including intra-bank transfers (within bank, also known as book transfers), inter-bank transfers within country and across borders, with its different flavours and schemes across countries and regions. It also supports many instant CT schemes that demands real time processing of credit transfers.

Direct Debits

Recurring or one-off request to collect money from a payer, based on a prior agreement (generally known as mandates). Direct debits are setup by corporate utility companies, who raise collection requests on a recurring basis to collect monies towards bills and invoices.

Temenos Payments fully supports initiation and processing of DD with an external mandate management system holding mandate information.

Cheques and Drafts

Supports processing of cheque payment processing, including cheque deposit, outward collection and inward collection, manual return and repair of cheque payments.

Request To Pay (RTP)

Allows payee to collect funds from a payer based on online authorisation (typically based on mobile devices).

Temenos Payments supports processing of RTP requests that include generation, receipt and processing of the request at payer bank side based on consent provided by the payer.

Payment Types

The different types of payment in Temenos Payments are as follows:




These payments are of high value, demanding gross settlement or international FX transactions. They can also be instant payments of low or high values. Temenos Payments supports single payments in all possible cases, including national and cross border payments.


To achieve cost effectiveness, transactions from corporate customers are combined into a batch and sent to their bank for processing. The batch transaction is an in-house transaction, while individual transactions in the batch are in-house or non-inhouse (off-us).

Temenos Payments supports single-debit multiple-credit CT and single-credit multiple-debit DD batches. It also supports splitting of batches into single individual transactions and processing them as individual transactions.

API Capabilities

Temenos Payments provides extensive capabilities around APIs. It provides functionalities that are exposed for consumption through its published APIs, API middleware, and powerful tools that allow banks to interface their systems with Temenos Payments with ease and effectiveness. The tools also allow on-the-fly creation and deployment of new APIs that a bank can develop to meet their specific channel and third-party requirements.

Multi-Function Capabilities

The multi-function capabilities of Temenos Payments are as follows:




Supports several banks with separated business rules and strictly segregated data. A company headquarter is defined at the highest level, under which multiple country level companies and branches within the country (if required) are defined.

The payment transaction and static data within Temenos Payments are associated with a company. Data visibility mechanism restricts users from viewing the company data (for defined companies). User application rights restricts the user from using system functions. It also allows companies to share data with each other, which enables the common set of users to manage payments for a group of companies.


Allows to configure multiple currencies with full-fledged set of currency attributes (such as currency markets, exchange rates, holidays, and possibility) to maintain them through manual or automatic feeds. It also supports cross-currency transactions with externally or internally stored exchange rates.


Supports multitude of languages and raises multi-lingual alerts, notifications, and processes payment transactions with multi-lingual fields.

Multi-Time Zone

Supports multi-time zone operations and assigns a time zone for each user and company. Users who belong to multiple companies can switch between time zones to operate effectively.

Instant Payments

Instant Payments processing framework is an extension of the Temenos Payments STP engine to meet the higher demands of instant processing payments. It offers the following features:

  • Receives, processes and responds to payments sent out in real-time (in milliseconds) in synchronous processing mode
  • 24*7 processing throughout the year with no downtimes
  • Near real-time synchronous processing (in seconds) for slower instant payment instruments to cope to bank’s technical infrastructure
  • Lightweight processing flows to achieve quick turnaround time
  • Automated investigation messages based on the needs of the instant clearing schemes
  • Time stamping (before release to clearing) and validation of the timestamp (on receipt from clearing)
  • Parallel processing capabilities to ensure maximum usage of time spent while waiting for external interfaces
  • Special R-processing functionality to meet instant payment schemes (for example, automatic scheme returns by instant clearing)
  • Real-time monitoring dashboard
  • Standby processing when bank hosts are offline due to (planned or unplanned) downtimes
  • Timeout and expiry mechanisms at integration layer

Illustrating Model Parameters

This section covers the high-level specifications required for the Temenos Payments module.




Configures various types of fee that are involved in processing a transaction

  • Conditional fee – For example, non-STP fee
  • Unconditional fee – For example, transaction fee


  • Specifies the codes to be used for MT940 (Tag61:Subtag6) and is linked with booking code (identified in Payment Order)
  • Once determined, the corresponding SWIFT transaction type code can be retrieved


  • Configures various currencies used in processing domestic or international transfers
  • Select other information such as the country to which the currency belongs to, specify FX limit, configure weekend days and so on


  • Determines the various parties involved in a SWIFT or SEPA transfer
  • For example, ordering customer, sending institution, beneficiary


Defines a set of pre-defined steps that influences payment processing by setting various fields and indicators that are subsequently read and considered for payment processing.


  • Stores the action to be performed for the corresponding status codes of the payment
  • Has information about the error codes and status code


  • Has information about programs executed in Temenos Payments
  • Details include name of the program, type of the program, name of the component to which the program belongs and path where it needs to be executed


  • Defines parameters for determination of Reject Response Action field
  • Allowed values are:
    • R – Sent to repair
    • C – Sent for cancellation


  • Indicates whether manual authorisation is required by COA Officer to process the payment
  • Allowed values are:
    • N – Manual authorisation request cannot be requested
    • Y – Manual authorisation request can be requested

NOTE: If not defined, by default, manual authorisation request can be requested.


  • Configures the filtering products
  • Used in PP.FILTERING.PAYMENTS table and derived as one of the output in product determination


Defines different filtering payments


Maintains the bank charges where, inn case of OUR payments, the processing bank either receives charges from the sending bank or sends charges to the receiving bank as all charges are borne by the originating party


  • Defines the way in which a payment should be processed in the payment engine for a correspondent bank
  • Various bank conditions include STP flow, charge account, statements and advices with correspondent bank


Stores the configuration required for bank preferences for claims processing


Defines various valid messages payment types such as 101, 103, 202, BACSCT, BACSDD supported by Temenos Payments


Defines various message formats

NOTE: Only when the message format is defined, other particulars of the message format can be defined in other tables of Temenos Payments.


Stores various channels using which a message is received from or sent to from Temenos Payments


  • Configures the source product group, which is used to group different sources
  • Every source in Temenos Payments is categorised in a source group
  • As a result, source product group needs to be defined before defining a source


Has configurations according to queue name specified with its folder path to receive messages


Stores inbound code word details for different types of incoming payments that alters the characteristics of the payment such as priority and processing indicator


  • Configures Balance Check Required field based on certain characteristics of the payment
  • Allowed values are:
    • Y – Balance check required
    • N – Balance Check not required



  • Holds the levels of authorisation of a manually processed payment or a cancelled warehouse payment.
  • Allowed values are:
    • 1 – 4 Eye Principle
    • 2 – 6 Eye Principle


Has various message formats in accordance with various channels available in Temenos Payments. There are many relationships between the message formats and channels.


Defines parameters for mapping messages received in Temenos Payments using API


  • Stores the details of various source from which a message is received in Temenos Payments
  • A source can be defined only along with Channel Name, Source Product and Source product group


  • Configures parameters related to Message Acceptance process
  • Specifies if duplicate check is to be performed for the incoming message


  • Stores specific weight to be used for payments to enforce special processing rules.
  • Two types of weight are assigned to every payment:
    • High level weight – Refers to an overall classification of the payment on a very broad level
    • Specific weight – Refers to a detailed weight assigned to a payment to trigger different flavors of a component for certain groups of a payment


  • Specifies physical programs to be invoked by each component according to weight and specific weight of the payments leading to reduction in processing time
  • Defines whether a component needs to be skipped


  • Defines list of message types that needs to skip debit authority check
  • If a record is present in this table, the payment is authorised straightforward


Stores many-to-many relation between message payment type and channels


Defines whether a Customer Status Report needs to be generated for a particular source


Configures clearing return code for the respective clearing


  • Defines clearing nature code along with description for all clearings defined in Temenos Payments
  • Stores other details related to the clearing such as Cheque Type, DD Collection and so on


Defines generic settings for clearing such as Direction, Currency, Clearing Account Number and Automated Return Indicator


  • Defines cut-off time for various channels used in Temenos Payments
  • Ensures the time beyond which the channel cannot be used to route a normal payment to the recipient


Stores the various clearing used for settlements in Temenos Payments based on currency and country code


Configures the cut-off time on which a Nostro settlement process with clearing house is to be started


Defines payment features specific to a product such as instant, domestic, SEPA and international


  • Stores posting products that are used while generating posting entries in Temenos Payments
  • Derived as one of the output of product determination


  • Defines routing products used in product determination process
  • Product defined is used while configuring client conditions


  • Configures a product related to client conditions
  • One of the criteria for selection of a record based on peeling off logic in client conditions table


  • Defines the fee products in Temenos Payments
  • Used in client charges table and derived as one of the output of product determination


  • Setup ledger product codes with product description for a processing company in different languages
  • The ledger codes are used extensively while posting


Attaches statement lines to the statement format already configured in the posting set in Temenos Payments


Stores the information about routing and settlement channel selection list


  • Specifies special condition or possible options for the customers
  • It can be defined very generic and specific to particular client


Defines the charges to be levied on a customer based on the product determined for the payment


Defines the posting set to be selected based on Company Code, Posting Product and set of payment file fields that are updated based on client conditions


Stores the routing and settlement information based on credit party of a payment or for the destination country of a payment. The three contract types are:

  • Party contract – Defined for credit party (most specific)
  • Country contract – Defined for destination country(less specific)
  • Bank contract – Defined for bank policy (least specific)


  • Defines various characteristics to determine a product for lightweight payment.
  • The determined product is linked to various factors such as Fee, Ledger, Client Condition, Posting and Routing product

NOTE: All incoming or re-direct domestic payments using Clearing channels are treated as light weight


  • Defines various characteristics to determine a product for heavy weight payment
  • The determined product is linked to various factors such as Fee, Ledger, Client Condition, Posting and Routing product

NOTE: Usually, all international domestic payments (outgoing or book) are categorised as heavy weight.


  • Defines various characteristics to determine a product for medium weight payment
  • The determined product is linked to various factors such as Fee, Ledger, Client Condition, Posting and Routing product

NOTE: Medium weight is specifically meant for SEPA


  • Defines each company that should participate in processing payments
  • Also defines attributes such as Local Currency, Company BIC, Country and so on


  • Stores different regions within a country
  • A region can be used to differentiate between holidays applicable for different locations within a country
  • If set as ALL, the setup is applicable for all regions of the country.


Configures error messages of type, Warnings and Information in Temenos Payments and they cannot be amended

  • Information – Can be ignored in UI flows
  • Warning – Needs to be accepted before payment authorisation


Stores the various status code in Temenos Payments along with the reason code and is only for informational purpose


Configures APIs which enable user defined handling of restrictions on account and customer


  • Defines various types of transaction and its description in Temenos Payments
  • Indicates the codification of the transaction type


  • Defines the companies, which support message received from payment router channel
  • During validation, if the company code in the message does not match with table the message is available in Repair status.


Stores the suspense account per company or currency for batch messages in Temenos Payments


Configures companies that support a specific clearing house along with other particulars such as National ID and so on

NOTE: This table is referred during validation of a clearing file to determine the company ID.


Defines the list of tables to be retrieved, while invoking OutwardMappingFramework.getAllTransactionData method by an external system


Configures values which should be mapped or override the values returned by Return API while generating return or reject payments and to attach a hook routine which defines specific logic (conditional mapping) required for populating values in return or reject payment


  • Stores code words to be added as outbound code words to be sent from Temenos Payments
  • Specifies the receiver BIC, message payment type and transaction currency


Helps the mapping of the inbound code words received in the incoming redirect payments to the outgoing redirect payment


  • Maintains various Service Level Agreement (SLA) with correspondent banks for each company
  • SLA is defined based on the Message Priority, CodeWord and the message tag in which the code word is specified


  • Stores netting agreement, which is a 3-party agreement between the sending bank, the processing bank and the customer
  • Confirms whether the sender of the payment instruction has the authority to mention a third party as the debit party for the payment


  • Configures a product related to client conditions
  • This is one of the criteria for selection of a record based on peeling off logic in client conditions table


  • Holds the publicly known Head Office-Branch relationships between banks
  • This is referred using a BIC and not NCC

NOTE: If only NCC is available, BIC is derived out of NCC and then this table is referred.


  • Stores the accounts of the correspondent banks with which the bank shares a Loro and Nostro relationship
  • Linked with BIC table and is also company specific


  • Stores referred correspondents that a company uses to route a payment to specific country.
  • More than one preferred correspondent for a country can be provided based on the currency of the transaction and routing group.
  • Preferred Correspondents are also known as Country Correspondents


  • Supports processing or redirecting credit transfer files from Indirect Participant (IP) banks through an IP bulk channel
  • Configures settlement account, BIC and NCC of each IP


  • Has the list of correspondent banks to which the bank is authorised to send a SWIFT message
  • The permissions on the RMA table are specific to the SWIFT NET service and message type
  • SWIFT service now can only be SWIFT NET FIN service


Specifies the list of message types for which RMA check is not required to send a SWIFT Message from Temenos Payments


  • Configures standing settlement instructions for correspondent banks.
  • They are also known as currency correspondents similar to PP.AGENT
  • Also refers to BIC and not NCC


Validates the extracted bank code (IBAN national ID) from the IBAN against the exclusion list

NOTE: In case of an invalid IBAN, the system must return a warning.


Configures setup parameters for calculation of debit value date, which can be processed by Temenos Payments using peeling logic


Defines the interdependency between the various dates used in Temenos Payments so that the same can be processed using peeling logic


Setup parameters for calculation of exposure date, which can be processed by Temenos Payments using peeling logic. 

NOTE: Exposure date is the date from which credited funds are available for use by the client.


Configures parameters that decide the holidays to calculate the next business day

NOTE: This is processed by Temenos Payments using peeling logic.


Stores the parameters to be considered to derive the date when the output message is to be sent to the receiving bank or clearing


Defines the risk filtering conditions for correspondent banks, country and currency wise


  • Stores the credit accounts linked with the fee types defined in Temenos Payments
  • During the fee processing, a lookup is performed to identify the associated credit account (P&L account)
  • This credit account along with the other charge details are used to post entries into the general ledger


  • Defines open currency positions that are used in posting when currency conversion is involved. OCP accounts are currency specific.
  • Temenos Payments selects the OCP account from the static table based on the currencies involved


  • Defines the dealer desk code for different types of currencies available in Temenos Payments
  • This code is required exclusively in posting the transaction entries


Defines the details of the account to be debited for the outgoing payment with charges option as OUR (receiving bank 71G) if the sending bank has not sent the sufficient charges


Configures amount, account, date and statement text tokens used in posting lines generated in Temenos Payments.


Configures the expected claims account and the expected P&L account for a currency and company code combination


  • Configures repair instances used in Temenos Payments. External repair tools are primarily designed to enhance straight-through-processing (STP) rate of the bank
  • The output of the repair tool is the input for the fee processing


Configures the description and meaning of the return codes returned by a repair instance defined in Temenos Payments


Displays details from the files received by the payment system from clearing


Configures fields to map the response details received from the external system


If a bank’s core-banking system is external to Temenos Transact (that is customer accounts is not in Temenos Transact), the system can skip the interaction with the external system for account validation when non-customer accounts that are frequently used do not undergo much change.


  • Stores the Source and Target fields with UTF characters.
  • Replaces the Source UTF-8 into Target UTF-8 when any special characters are mentioned in SWIFT and SEPA transfers. In the below example, Ü is converted to AB wherever used in payment message.
    • Source – U+0060 equivalent value is Ü
    • Target1 – U+0041 equivalent value is A
    • Target2 – U+0042 equivalent value is B