System Properties

The Mambu Payment Gateway (MPG) has multiple configuration options to address your needs. All these options are available in the System Properties page, under the Configuration section of the MPG side menu. In the following article, we will describe what each configuration option does, as well as provide some examples.

The system properties page is split into sub-sections, each with a group of related properties.

Some of the configuration options in this article are marked as Deprecated. These have no effect regardless of the value and are scheduled for removal or change.

Basic configuration

This section contains the minimum set of information required for MPG to function correctly. It allows you to specify the Bank Identifier Code (BIC) of your bank and the automated clearing house (ACH) as well as the ACH system.

The table lists the available fields in the basic configuration section and you may select the field title for more information.

Below is more information about each field.

Bank Identifier Code

This is the BIC of your bank or financial institution.

When first setting your basic configuration, you must provide the Bank BIC and local bank codes to the Mambu team so that they can finish setting up the payments system.

By default, all newly created schedulers will be running using this BIC. This value will be populated under InstgAgt>FinInstnId>BIC in the group header of the generated outgoing messages, and incoming schedulers will pick up incoming messages, which have the same InstdAgt>FinInstnId>BIC value as the current BIC.

In this example, outgoing schedulers will be generating Single Euro Payments Area (SEPA) messages with TESTBICA as the value for GrpHdr>InstgAgt>FinInstnId>BIC, and incoming schedulers will be picking up incoming SEPA messages, which have TESTBICA as the value for GrpHdr>InstdAgt>FinInstnId>BIC .

The Mambu Payment Gateway also offers support for multiple BICs. For more information, see Schedulers.

ACH BIC

This is the BIC code of your Automated Clearing House (ACH), also sometimes referred to as Clearing and Settlement Mechanism (CSM). It is populated under the InstdAgt>FinInstnId>BIC in the generated message header. In this example, outgoing schedulers will be generating SEPA messages with GrpHdr>InstdAgt>FinInstnId>BIC, with the value TESTBICB.

ACH System

This is the proprietary code of the clearing system type. It is populated under ClrSys>Prtry in the generated message header. In this example, Outgoing Schedulers will be generating SEPA messages with ST2 as the value of GrpHdr>SttlmInf>ClrSys>Prtry.

Extra System Properties

The extra system properties section allows you to configure parameters related to security.

Password Expiration Days

This is the password expiration for user accounts in days. After which the user will be prompted to change their password. In this example, if a user has not updated their password in the past year, they will be redirected to the password change page upon logging in.

Failed login attempts

This is the number of failed login attempts allowed for user accounts before their account gets disabled and needs to be re-enabled by an administrator. In this example, if a user fails to login five or more times consecutively, their account will be automatically disabled. An MPG user with administrator permissions is then able to re-enable the account.

Number of password history to keep

This is the number of previous passwords a user is forbidden to re-use when changing their password. In this example, the MPG users cannot use any of the previous five passwords when configuring a new one.

Password Minimum Length

If a value is provided here, users will not be able to set passwords that do not meet this minimum length. The default minimum length of passwords is eight characters. In the example, users would need to use 13 or more characters in their passwords.

Test code - Deprecated

Outgoing transactions limit

This is the limit of transactions which will be included inside Outgoing SEPA Credit Transfer (CT) pacs.008 and Anti-Money Laundering (AML) pacs.008 messages. In this example, if there are 20 pending outgoing transactions, two pacs.008 messages with 10 transactions each will be generated and sent to the configured callout.

Callout Configuration

The callout configuration allows you to specify the settings for the system where your payment messages will be sent.

Target URL

Callout URL to which payment messages should be sent. It must support POST and PUT requests with an application/xml body.

HTTP Method

HTTP method to be used when calling the callout URL. POST or PUT are currently supported.

Content Type

Content type to be used when calling the callout URL. Only application/xml is supported.

Authorization type

Authorization type to be used when calling the callout URL. No authorization and Basic authorization are currently supported. When selecting Basic authorization, you must also specify the username and password.

Retry policy

The retry policy for all Mambu Payment Gateway callouts (for example, for SEPA and AML) is as follows.

When a callout fails - with a responce of 4xx, 5xx, or timed out - an alarm is raised in the MPG alerts section containing the following information:

• Failure reason
• Number of retries executed so far

The callout will be automatically sent out again on the next outgoing scheduler run, as per your configuration. For example, if your outgoing scheduler is configured to run twice a day and it fails the first time, then the callout will be retried only once on that day, and twice every following day, until it succeeds.

Incoming Direct Debit Configuration

Maximum allowed days to retry

When receiving an incoming SEPA Direct Debit (DD) instruction which initially fails (for example insufficient amount), the debtor bank can retry the debit transaction for a specific number of days before sending back a return instruction. This option specifies the maximum number of days to retry failed debit transactions before returning the DD transaction. In this example, the Mambu Payment Gateway will retry the debit transaction for four days, according to the Incoming SEPA DD Retry Scheduler configuration, before sending an outgoing return instruction on the fifth day.

AML Configuration

If AML is enabled, the Mambu Payment Gateway will send the incoming credit instruction to your AML service for a compliance check.

The check should be performed in the external system and the results should be delivered via API. It is possible to configure multiple AML statuses that can be reflected in the screen to show the current state of the transaction.

AML Credit Transfer Incoming Enabled

If enabled, Incoming SEPA Credit Transfers will be sent to the AML Callout URL for AML verification before being credited to the client account. If disabled, Incoming SEPA Credit Transfers will be immediately credited to the client account.

AML Credit Transfer Outgoing Enabled

If enabled, Outgoing SEPA Credit Transfers will be sent to the AML Callout URL for AML verification after the amount has been debited from the client account, but before the actual SEPA pacs.008 message has been sent to the Callout URL. If disabled, Outgoing SEPA Credit Transfers will be sent to the Callout URL without passing through the AML checks.

AML Direct Debit Incoming Enabled

If enabled, Incoming SEPA Direct Debits will be sent to the AML Callout URL for AML verification before being debited from the client account. If disabled, Incoming SEPA Direct Debits will be immediately debited from the client account.

AML Direct Debit Outgoing Enabled

If enabled, Outgoing SEPA Direct Debits will be sent to the AML Callout URL for AML verification before the actual SEPA pacs.003 message has been sent to the Callout URL. If disabled, Outgoing SEPA Direct Debits will be sent to the Callout URL without passing through the AML checks.

AML Incoming Message Split Enabled

When incoming SEPA Credit Transfers or Direct Debits are received and Incoming AML is enabled, the file is sent to the configured AML callout as a whole. In cases where the system targeted by the AML callout does not support handling of very large files, the Mambu Payment Gateway is now able to split the Incoming instruction into multiple smaller instructions before sending each of them to the AML callout.

If the flag is set, you will be able to input the AML Incoming Message Transaction Batch Limit. When a value larger than zero is configured, for each incoming instruction which contains more than AML Incoming Message Transaction Batch Limit transactions, the MPG will split it up in batches which contain a maximum of AML Incoming Message Transaction Batch Limit transactions. All Group Header information will remain the same, except the Total Number of Transactions and Total Amount, which will reflect the actual information from the batch.

In this example, incoming messages with more than 10 transactions will be split into multiple smaller instructions with at most 10 transactions each before being sent to the AML callout.

Target URL

AML Callout URL to which SEPA messages should be sent for AML verifications.

HTTP Method

HTTP method to be used when calling the Callout URL. POST or PUT are currently supported.

Content Type

Content type to be used when calling the Callout URL. application/xml and application/json are supported. Selecting one of them means that the AML Callout request will be of the specified type: XML or JSON.

Authorization type

Authorization type to be used when calling the Callout URL. No authorization and Basic authorization are currently supported. When selecting Basic authorization, you must also specify the Username and Password, as shown in the picture.

AML Suspense Accounting IDs

If AML Suspense Accounting Enabled is selected, AML Suspense Accounting flows will be executed when a transaction is AML Suspended. More information about this feature is available in the AML & Suspense Accounting section.

After enabling AML Suspense Accounting, a new section will be available giving the possibility to set a Suspense Account for each BIC. All suspended incoming or outgoing payments which were initiated with a specific BIC will be redirected to the Suspense Account assigned to it.

In this example, two separate BICs are configured in the MPG, and a Suspense Account ID is specified for each of them.

Message processing configuration

The message processing configuration settings control whether there is automatic processing and, in some cases, response generation for certain message types. If automatic processing is not enabled, the response messages will generally need to be manually sent using the Mambu Payment Gateway UI.

Automatically respond with negative response for failed recalls due to business reasons

If this flag is enabled, when a camt.056 Recall instruction processing fails due to a business reason (for example, account locked or not enough balance), a negative response with reason code AGNT will be automatically published. If this flag is disabled, the negative response must be manually triggered via the SEPA CT Pending section under Authorization from the UI. This flag is enabled by default.

Automatically process pacs.002.001.03 messages with RJCT group status

If this flag is enabled, when an incoming pacs.002 rejection instruction is received with RJCT as group status, all transactions from the original pacs.008 instruction will be reverted. If this flag is disabled, transactions will no longer be automatically reverted, and instead the MPG will wait for some manual input to fix the original pacs.008 instruction and re-send it to the configured Callout. You can spot the Rejected transactions either in the MPG UI or the Instructions API, and then contact us to fix and reprocess the pacs.008 instruction. This flag is enabled by default. Please contact us through Mambu Support.

Generate positive pacs.002.001.03 messages for Credit Transfers

When this setting is enabled the system will generate a positive payment status report (pacs.002.001.03 message) when all payments from an incoming SEPA credit transfer message have been settled. The group status (<GrpSts>) of the message will have the value ACCP. This is not a standard SEPA European Payments Council (EPC) message or business flow, thus the functionality can be enabled through this flag. This flag is enabled by default.

Generate positive pacs.002.001.03 messages for Credit Transfers with service level TGT

When this setting is enabled the system will generate a positive payment status report (pacs.002.001.03 message) when all payments from an incoming message where the TARGET2 settlement method was used, have been settled. The group status (<GrpSts>) of the message will have the value ACCP. This is not a standard SEPA EPC message or business flow, thus the functionality can be enabled through this flag. This flag is enabled by default.

Generate UETR-compliant Transaction ID for outgoing Credit Transfers with service level TGT

If payments with service level TGT are supported, enabling this property will allow generating the Transaction ID as an UUIDv4 without dashes, if not provided. The value of the Transaction ID is the actual outgoing Payment Order ID.

Automatically process requests for Status Update on Recall

If this flag is enabled, when a Request for Status Update for a Recall instruction is received (pacs.028.001.01), it will be automatically processed by the MPG and a negative response (camt.029.001.03) will be generated and sent out. If disabled, Status Update instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default.

Automatically process requests for Status Update on SCT Inquiry

If this flag is enabled, when a Request for Status Update for an SEPA Credit Transfer (SCT) Inquiry instruction is received (pacs.028.001.01), it will be automatically processed by the MPG and a negative response (camt.029.001.08) will be generated and sent out. If disabled, Status Update instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default.

Automatically process Claims Non-Receipt

If this flag is enabled, when a Claim of Non-Receipt (camt.027.001.06) for an SCT instruction is received, it will be automatically processed by the MPG and a negative response (camt.029.001.08) will be generated and sent out. If disabled, SCT Inquiry instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default.

Automatically process Claims for Value Date Correction

If this flag is enabled, when a Claim of Non-Receipt (camt.087.001.05) for a SCT instruction is received, it will be automatically processed by the MPG and a negative response (camt.029.001.08) will be generated and sent out. If disabled, SCT Inquiry instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default.

Settle Incoming SEPA Instant Asynchronously

With this flag enabled, the processing of an Incoming SEPA Instant payment will pause after the Positive Status Report Message (pacs.002.001.03) is sent to the relevant Clearing and Settlement Mechanism (CSM). The processing will continue and the settlement will take place after a POST request is made to the api/v1/payments:settleInstantPayment endpoint. For more information, see settleInstantPayment in our Payments API Reference.

SMS Configuration

The SMS configuration section is available to you if you want to use multi-factor authentication (MFA). For more information about enabling MFA for MPG users, see User Administration and Audit Trail - Multi-factor authentication.

SMS Gateway

SMS system to be used for sending Multi-Factor Authentication (MFA) SMS messages. Currently TWILIO and INFOBIP are supported, or NONE. If one of the first two options are selected, you must input the following information as well.

Account Username

Username to be used for authentication with the SMS Gateway.

Account Password

Password to be used for authentication with the SMS Gateway.

Phone Number

Actual phone number from which the SMS messages will be sent.