Electrum Regulated Payments API (34.1.0)

The Electrum Regulated Payments API is an asynchronous API that allows partners to participate in various nationally regulated payment schemes.

This document describes the operations exposed by Electrum for partners to consume in order to initiate outbound or respond to inbound payments.

As the Regulated Payments API is asynchronous, partners have a choice of how to integrate with Electrum:

Webhooks: Electrum will send events to the partner containing inbound payments to action, or responses to outbound payment requests. Webhooks are defined in this document.
Partner API: Electrum will call operations exposed by the partner containing inbound payments to action, or responses to outbound payment requests. The operations are defined in the Electrum Regulated Payments Partner API.

Receiving transactional events via webhooks or API are equivalent, except that it may be more familiar or convenient to implement one style or the other. Partners may request the method of communication Electrum should use when selecting which payment schemes to participate in.

Download OpenAPI description

elpapi-redoc.json

elpapi-redoc.yaml

Overview

URL

https://electrum.co.za

Electrum Support

support@electrum.co.za

License

proprietary

Servers

Payments API sandbox

https://example.com/path/payments/api/v1/

transactional

Operations that participate in transaction processing, which may or may not have financial impact.

Operations

financial

Operations that participate in transaction processing and have financial impact.

Operations

credit-transfer

Operations related to credit transfer transactions.

Operations

direct-debit

Operations related to direct debit transactions.

Operations

payment-return

Operations related to payment returns.

Operations

payment-cancellation

Operations related to the cancellation of prior payment instructions.

Operations

account-management

Operations that involve customer account information.

Operations

proxy

Operations that involve the management or processing of proxies

Operations

scheme-inquiry

Operations that are related to retrieving information from industry for a particular scheme.

Operations

identifier-determination

Operations used to retrieve additional information related to an identifier

Operations

identifier-verification

Operations used to verify information relating to an account identifier

Operations

request-to-pay

Operations which pertain to a request for payment from a creditor to a debtor

Operations

funds-management

Operations related to the management of funds, including reservations, postings, and voiding of reservations.

Operations

refund

Operations related to the refund of a prior successful financial transaction.

Operations

risk-assessment

Operations related to the assessment and identification of risk in transactions.

Operations

fraud-assessment

Operations related to the processing of fraud assessments for payment transactions.

Operations

sanctions-assessment

Operations related to the processing of sanctions assessment for payment transactions.

Operations

mandate-management

Operations related to the lifecycle management of direct debit mandates.

Operations

Schema

ZaAcMandatePaymentScheme

schemastring(PaymentSchemeName)required

Identifies the scheme used for the payment

ZA_RTC: South African Realtime Clearing scheme.
ZA_RPP: South African Realtime Payments Platform scheme.
ZA_EFT: South African Electronic Funds Transfer scheme.
ZA_AC : South African Authenticated Collections scheme.
ZA_RMS: South African Registered Mandate Service scheme.
CBPR_PLUS: Cross-Border Payments and Reporting Plus.
TCIB: Transactions Cleared on an Immediate Basis scheme.

Enum"ZA_RTC""ZA_RPP""ZA_EFT""ZA_AC""ZA_RMS""CBPR_PLUS""TCIB"

schemeDataobject(ZaAcMandatePaymentSchemeData)required

South Africa specific supplementary data fields. These fields supplement the core mandate structure with local requirements.

schemeData.amendmentTypestring

Identifies the type of mandate amendment being requested. This is required for every MandateAmendmentRequest, and is echoed on the acceptance report for that request. It is not applicable to any other mandate operation and should be omitted from those.

Cession and assignment is carried by the same amendment operation as a routine amendment, but it is an operationally a different workflow, so it is stated explicitly here rather than being inferred from the local instrument code.

CONTRACT_AMENDMENT: A routine (business as usual) amendment to the terms of an existing mandate.
CESSION_AND_ASSIGNMENT: The transfer of a mandate, or a book of mandates, to a different creditor, sponsoring bank or ultimate creditor. Only administrative and creditor fields may be changed - the core contract and payment terms cannot be modified during a cession. Cession and assignment additionally requires prior approval.

Enum"CONTRACT_AMENDMENT""CESSION_AND_ASSIGNMENT"

schemeData.authenticationTypestringrequired

Indicates the delivery and authentication mechanism of the mandate transaction.

In the ZA_AC scheme, this field dictates the specific Transaction Type (TT) processing rules that will be applied:

REAL_TIME: Maps to TT1 (non-card). The mandate request is routed over the real-time interbank switch without an upfront authentication key. Note: The actual Payer authorisation might be immediate (e.g., 120-second USSD timeout) or delayed (until the end of the day), but the routing type remains REAL_TIME.
PREAUTH: Maps to TT3 (Card Present). Indicates the Payer has already been authenticated via a prior card-and-PIN transaction at the point of interaction. Mandates using this type must include the resulting Message Authentication Code (MAC) in the request payload.
BATCH: Maps to TT2. The mandate request is submitted via delayed bulk file processing.
NOT_APPLICABLE: Debtor authentication is not required for this action (e.g. MandateInformationRequest).

Enum"REAL_TIME""PREAUTH""BATCH""NOT_APPLICABLE"

schemeData.debtorBankMandateReferencestring<= 22 characters^[0-9]{4}20[0-9]{2}[0-1][0-9][0-3][0-9].{10}$...

The Mandate Reference Number (MRN) assigned by the debtor bank upon mandate acceptance. This is the official, unique industry-wide identification number for the mandate that is unique for the mandate's entire lifecycle (including time in archives).

It is returned in the acceptance report and must be included in subsequent mandate amendment, and suspension requests.

Not to be confused with mandateIdentification (the creditor's internal ID) or mandateRequestTransactionIdentifier (MRTI).

Structure (22 characters):

Bank Number (4 numeric): The 4-digit identifier of the Debtor Bank.
Mandate Creation Date (8 numeric): The date the mandate was successfully registered, formatted strictly as YYYYMMDD.
Free Format (10 alphanumeric): A unique identifier or sequence generated by the Debtor Bank.

schemeData.mandateRequestTransactionIdentifierstring(MandateRequestTransactionIdentifier)<= 35 characters^\d{4}\d{4}-\d{2}-\d{2}\d{9}$

Mandate Request Transaction Identifier (MRTI) A unique transaction identifier used for matching multiple messages to a single transaction. This identifier is created for each new mandate request to uniquely identify the transaction within the Authenticated Collections scheme.

Important: Usage of mandateRequestTransactionIdentifier**.

If the client is the host of the mandate register and is the source of truth for mandate state the client is required to always populate the MRTI. The format is validated and the provided MRTI is used by Electrum.
If Electrum is the source of truth for mandate state the MRTI should not be provided by the client when initiating new mandate transactions; Electrum will generate a compliant MRTI automatically which will be echoed back to the client.

Structure (23 characters):

Positions 1–4 (4 numeric): Originating bank number. Must be a valid, registered bank.
Positions 5–14 (10 alphanumeric): Origination date in the format YYYY-MM-DD. Must be a valid date.
Positions 15–23 (9 numeric): Mandate sequence number. Unique within the bank and date.

Lifecycle behaviour:

Mandate Initiation Request: The originating bank creates a new, unique MRTI for the initiation request. If not provided by the client, Electrum generates one automatically.
Mandate Amendment Request: A new, unique MRTI is required for the amendment request. If not provided by the client, Electrum generates one automatically. The amendment is linked back to the original mandate using the Mandate Reference Number (MRN).
Mandate Cancellation Request:
- In-flight cancellation: If cancelling a mandate request that is still in-flight (e.g. awaiting debtor authentication), the MRTI must exactly match the MRTI of the in-flight request being cancelled. If not provided, Electrum handles this automatically by retrieving the MRTI of the in-flight transaction.
- Active mandate cancellation: If the mandate is already fully registered and active, a new, unique MRTI must be issued for the cancellation request. If not provided, Electrum determines the mandate state and applies the correct rule automatically.
Mandate Acceptance Report: The response echoes back the MRTI from the request being responded to. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.
Mandate Status Report: The status report echoes back the MRTI from the request being reported on. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.

Validation rules enforced by the scheme:

Must not be blank or spaces.
The bank number (positions 1–4) must be a valid, registered bank.
The date (positions 5–14) must be a valid calendar date.
Must conform to the 23-character structured format.
Must be unique at the time of request origination.

schemeData.requestTransmissionNumberinteger(MandatePaymentSchemeRequestTransmissionNumber)[ 1 .. 4 ]

Sequence number for the message's transmission. Used exclusively for real-time (TT1/TT3) messages to track message retries. 1 = original message transmission, 2-4 = retries.

{
  "schema": "ZA_RTC",
  "schemeData": {
    "amendmentType": "CONTRACT_AMENDMENT",
    "authenticationType": "REAL_TIME",
    "debtorBankMandateReference": "string",
    "mandateRequestTransactionIdentifier": "string",
    "requestTransmissionNumber": 1
  }
}

MandatePaymentScheme

Designates which scheme a mandate operation is associated with and describes scheme-specific information for the mandate operation where relevant.

schemastring(PaymentSchemeName)required

Identifies the scheme used for the payment

ZA_RTC: South African Realtime Clearing scheme.
ZA_RPP: South African Realtime Payments Platform scheme.
ZA_EFT: South African Electronic Funds Transfer scheme.
ZA_AC : South African Authenticated Collections scheme.
ZA_RMS: South African Registered Mandate Service scheme.
CBPR_PLUS: Cross-Border Payments and Reporting Plus.
TCIB: Transactions Cleared on an Immediate Basis scheme.

Enum"ZA_RTC""ZA_RPP""ZA_EFT""ZA_AC""ZA_RMS""CBPR_PLUS""TCIB"

Discriminator

schemeDataobject(ZaAcMandatePaymentSchemeData)required

South Africa specific supplementary data fields. These fields supplement the core mandate structure with local requirements.

schemeData.amendmentTypestring

CONTRACT_AMENDMENT: A routine (business as usual) amendment to the terms of an existing mandate.
CESSION_AND_ASSIGNMENT: The transfer of a mandate, or a book of mandates, to a different creditor, sponsoring bank or ultimate creditor. Only administrative and creditor fields may be changed - the core contract and payment terms cannot be modified during a cession. Cession and assignment additionally requires prior approval.

Enum"CONTRACT_AMENDMENT""CESSION_AND_ASSIGNMENT"

schemeData.authenticationTypestringrequired

Indicates the delivery and authentication mechanism of the mandate transaction.

In the ZA_AC scheme, this field dictates the specific Transaction Type (TT) processing rules that will be applied:

REAL_TIME: Maps to TT1 (non-card). The mandate request is routed over the real-time interbank switch without an upfront authentication key. Note: The actual Payer authorisation might be immediate (e.g., 120-second USSD timeout) or delayed (until the end of the day), but the routing type remains REAL_TIME.
PREAUTH: Maps to TT3 (Card Present). Indicates the Payer has already been authenticated via a prior card-and-PIN transaction at the point of interaction. Mandates using this type must include the resulting Message Authentication Code (MAC) in the request payload.
BATCH: Maps to TT2. The mandate request is submitted via delayed bulk file processing.
NOT_APPLICABLE: Debtor authentication is not required for this action (e.g. MandateInformationRequest).

Enum"REAL_TIME""PREAUTH""BATCH""NOT_APPLICABLE"

schemeData.debtorBankMandateReferencestring<= 22 characters^[0-9]{4}20[0-9]{2}[0-1][0-9][0-3][0-9].{10}$...

It is returned in the acceptance report and must be included in subsequent mandate amendment, and suspension requests.

Not to be confused with mandateIdentification (the creditor's internal ID) or mandateRequestTransactionIdentifier (MRTI).

Structure (22 characters):

Bank Number (4 numeric): The 4-digit identifier of the Debtor Bank.
Mandate Creation Date (8 numeric): The date the mandate was successfully registered, formatted strictly as YYYYMMDD.
Free Format (10 alphanumeric): A unique identifier or sequence generated by the Debtor Bank.

schemeData.mandateRequestTransactionIdentifierstring(MandateRequestTransactionIdentifier)<= 35 characters^\d{4}\d{4}-\d{2}-\d{2}\d{9}$

Important: Usage of mandateRequestTransactionIdentifier**.

If the client is the host of the mandate register and is the source of truth for mandate state the client is required to always populate the MRTI. The format is validated and the provided MRTI is used by Electrum.
If Electrum is the source of truth for mandate state the MRTI should not be provided by the client when initiating new mandate transactions; Electrum will generate a compliant MRTI automatically which will be echoed back to the client.

Structure (23 characters):

Positions 1–4 (4 numeric): Originating bank number. Must be a valid, registered bank.
Positions 5–14 (10 alphanumeric): Origination date in the format YYYY-MM-DD. Must be a valid date.
Positions 15–23 (9 numeric): Mandate sequence number. Unique within the bank and date.

Lifecycle behaviour:

Mandate Initiation Request: The originating bank creates a new, unique MRTI for the initiation request. If not provided by the client, Electrum generates one automatically.
Mandate Amendment Request: A new, unique MRTI is required for the amendment request. If not provided by the client, Electrum generates one automatically. The amendment is linked back to the original mandate using the Mandate Reference Number (MRN).
Mandate Cancellation Request:
- In-flight cancellation: If cancelling a mandate request that is still in-flight (e.g. awaiting debtor authentication), the MRTI must exactly match the MRTI of the in-flight request being cancelled. If not provided, Electrum handles this automatically by retrieving the MRTI of the in-flight transaction.
- Active mandate cancellation: If the mandate is already fully registered and active, a new, unique MRTI must be issued for the cancellation request. If not provided, Electrum determines the mandate state and applies the correct rule automatically.
Mandate Acceptance Report: The response echoes back the MRTI from the request being responded to. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.
Mandate Status Report: The status report echoes back the MRTI from the request being reported on. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.

Validation rules enforced by the scheme:

Must not be blank or spaces.
The bank number (positions 1–4) must be a valid, registered bank.
The date (positions 5–14) must be a valid calendar date.
Must conform to the 23-character structured format.
Must be unique at the time of request origination.

schemeData.requestTransmissionNumberinteger(MandatePaymentSchemeRequestTransmissionNumber)[ 1 .. 4 ]

Sequence number for the message's transmission. Used exclusively for real-time (TT1/TT3) messages to track message retries. 1 = original message transmission, 2-4 = retries.

{
  "schema": "ZA_AC",
  "schemeData": {
    "amendmentType": "CONTRACT_AMENDMENT",
    "authenticationType": "REAL_TIME",
    "debtorBankMandateReference": "string",
    "mandateRequestTransactionIdentifier": "string",
    "requestTransmissionNumber": 1
  }
}

MandateInitiationRequest

A request to initiate a new mandate. Sent by the creditor to the debtor's bank to request establishment of a new mandate.

messageIdentifiersobject(MessageIdentifiers)required

Holds a point-to-point unique message identification string as well as a message's creation date time.

messageIdentifiers.creationDateTimestring(date-time)required

The date and time at which the message was created, in senders local timezone or UTC. The date must be formatted as defined by date-time in RFC3339

messageIdentifiers.messageIdentificationstring<= 35 charactersrequired

A reference used to unambiguously identify the message between the sending and receiving party. Take note that this uniquely identifies a single message in a potentially multi-message exchange to complete a payment.

supplementaryDataobject(SupplementaryData)

A list of key-value pairs to support adding any supplementary/additional data to an Electrum Regulated Payments API message.

initiatingPartyobject(Party)

This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.

instructedAgentobject(InstitutionIdentification)

instructingAgentobject(InstitutionIdentification)

mandateobject(Mandate)required

Core mandate data structure containing all the details of a direct debit mandate.

mandate.adjustmentobject(MandateAdjustmentRules)

Defines adjustment rules for mandate amounts.

mandate.authenticationobject(MandateAuthentication)

Identifies the specific mechanism or channel that the Paying Bank (Debtor Bank) uses to communicate with the Payer (Debtor) to obtain their authorisation for a mandate. This field may be missing on mandate initiation/amendment and should be populated by the debtor bank upon acceptance of the mandate

mandate.collectionAmountobject(Amount)

mandate.creditorobject(Party)

This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.

mandate.creditorAccountobject(PaymentAccount)

Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.

mandate.creditorAgentobject(InstitutionIdentification)

mandate.creditorSchemeIdentificationobject(Party)

This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.

mandate.debtorobject(Party)

This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.

mandate.debtorAccountobject(PaymentAccount)

Representation of an account for payment purposes. Note that at least one of identification or proxy is expected to be present.

mandate.debtorAgentobject(InstitutionIdentification)

mandate.firstCollectionAmountobject(Amount)

mandate.mandateIdentificationstring<= 35 characters

Unique identification of the mandate, as assigned by the creditor. This field is used strictly by the Creditor for their own internal referencing and may be used to link collections to their related mandate. This is required for mandate initiations and cancellations.

mandate.mandateRequestIdentificationstring<= 35 characters

Unique identification of the mandate request, as assigned by the creditor to the debtor when the underlying contract is concluded between the two parties. This field represents the Contract Reference Number. It appears on the debtor's bank statement to help them identify the deductions. The Contract Reference must remain unchanged for the entire duration of the mandate, even in the event of cession or assignment. It can only be amended if no AC Payment Instruction has ever been presented against the Payer's account. This field is required for mandate initiations and mandate cancellations.

mandate.mandateStatusobject(MandateStatus)

Current status of a mandate.

mandate.maximumAmountobject(Amount)

mandate.occurrencesobject(MandateOccurrences)

Defines the frequency and duration of mandate collections.

mandate.reasonobject(MandateReason)

Specifies the reason for a mandate action (amendment, cancellation, rejection).

mandate.referredDocumentArray of objects(ReferredDocument)

Provides information to identify the underlying documents associated with the mandate

mandate.trackingIndicatorboolean

Indicates whether the mandate permits tracking for future collection instructions. Its exact meaning and relevance depend strictly on the mandate-management operation being performed:

1. Mandate Initiation & Amendment Requests

Required: Specifies whether tracking capabilities are permitted (true) or revoked (false) for future collections against this mandate.

2. Mandate Cancellation Requests

Required: Acts specifically as a Tracking Cancellation Indicator to manage collections that are already in-flight.
- true: Instructs the clearing house to immediately cancel any active tracking records currently in the tracking queue for this mandate.
- false: Instructs the clearing house NOT to cancel records in tracking, allowing them to finish their tracking cycle despite the mandate being cancelled.

3. Mandate Acceptance Reports

Required: Echoes the definitive tracking setting (true or false) that was successfully saved to the Debtor Bank's Mandate Register.

4. Mandate Suspensions & Information Requests

Not Applicable: This field is ignored for lookup and suspension operations.

mandate.typeobject(MandateTypeInformation)

Provides details on the type of mandate.

mandate.ultimateCreditorobject(Party)

This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.

mandate.ultimateDebtorobject(Party)

This model is the basic representation of a Party. It is expanded on depending on whether the party is a person or an organisation.

paymentSchemeobject(MandatePaymentScheme)required

Designates which scheme a mandate operation is associated with and describes scheme-specific information for the mandate operation where relevant.

paymentScheme.schemastring(PaymentSchemeName)required

Identifies the scheme used for the payment

ZA_RTC: South African Realtime Clearing scheme.
ZA_RPP: South African Realtime Payments Platform scheme.
ZA_EFT: South African Electronic Funds Transfer scheme.
ZA_AC : South African Authenticated Collections scheme.
ZA_RMS: South African Registered Mandate Service scheme.
CBPR_PLUS: Cross-Border Payments and Reporting Plus.
TCIB: Transactions Cleared on an Immediate Basis scheme.

Enum"ZA_RTC""ZA_RPP""ZA_EFT""ZA_AC""ZA_RMS""CBPR_PLUS""TCIB"

Discriminator

paymentScheme.schemeDataobject(ZaAcMandatePaymentSchemeData)required

South Africa specific supplementary data fields. These fields supplement the core mandate structure with local requirements.

paymentScheme.schemeData.amendmentTypestring

CONTRACT_AMENDMENT: A routine (business as usual) amendment to the terms of an existing mandate.
CESSION_AND_ASSIGNMENT: The transfer of a mandate, or a book of mandates, to a different creditor, sponsoring bank or ultimate creditor. Only administrative and creditor fields may be changed - the core contract and payment terms cannot be modified during a cession. Cession and assignment additionally requires prior approval.

Enum"CONTRACT_AMENDMENT""CESSION_AND_ASSIGNMENT"

paymentScheme.schemeData.authenticationTypestringrequired

Indicates the delivery and authentication mechanism of the mandate transaction.

In the ZA_AC scheme, this field dictates the specific Transaction Type (TT) processing rules that will be applied:

REAL_TIME: Maps to TT1 (non-card). The mandate request is routed over the real-time interbank switch without an upfront authentication key. Note: The actual Payer authorisation might be immediate (e.g., 120-second USSD timeout) or delayed (until the end of the day), but the routing type remains REAL_TIME.
PREAUTH: Maps to TT3 (Card Present). Indicates the Payer has already been authenticated via a prior card-and-PIN transaction at the point of interaction. Mandates using this type must include the resulting Message Authentication Code (MAC) in the request payload.
BATCH: Maps to TT2. The mandate request is submitted via delayed bulk file processing.
NOT_APPLICABLE: Debtor authentication is not required for this action (e.g. MandateInformationRequest).

Enum"REAL_TIME""PREAUTH""BATCH""NOT_APPLICABLE"

paymentScheme.schemeData.debtorBankMandateReferencestring<= 22 characters^[0-9]{4}20[0-9]{2}[0-1][0-9][0-3][0-9].{10}$...

It is returned in the acceptance report and must be included in subsequent mandate amendment, and suspension requests.

Not to be confused with mandateIdentification (the creditor's internal ID) or mandateRequestTransactionIdentifier (MRTI).

Structure (22 characters):

Bank Number (4 numeric): The 4-digit identifier of the Debtor Bank.
Mandate Creation Date (8 numeric): The date the mandate was successfully registered, formatted strictly as YYYYMMDD.
Free Format (10 alphanumeric): A unique identifier or sequence generated by the Debtor Bank.

paymentScheme.schemeData.mandateRequestTransactionIdentifierstring(MandateRequestTransactionIdentifier)<= 35 characters^\d{4}\d{4}-\d{2}-\d{2}\d{9}$

Important: Usage of mandateRequestTransactionIdentifier**.

If the client is the host of the mandate register and is the source of truth for mandate state the client is required to always populate the MRTI. The format is validated and the provided MRTI is used by Electrum.
If Electrum is the source of truth for mandate state the MRTI should not be provided by the client when initiating new mandate transactions; Electrum will generate a compliant MRTI automatically which will be echoed back to the client.

Structure (23 characters):

Positions 1–4 (4 numeric): Originating bank number. Must be a valid, registered bank.
Positions 5–14 (10 alphanumeric): Origination date in the format YYYY-MM-DD. Must be a valid date.
Positions 15–23 (9 numeric): Mandate sequence number. Unique within the bank and date.

Lifecycle behaviour:

Mandate Initiation Request: The originating bank creates a new, unique MRTI for the initiation request. If not provided by the client, Electrum generates one automatically.
Mandate Amendment Request: A new, unique MRTI is required for the amendment request. If not provided by the client, Electrum generates one automatically. The amendment is linked back to the original mandate using the Mandate Reference Number (MRN).
Mandate Cancellation Request:
- In-flight cancellation: If cancelling a mandate request that is still in-flight (e.g. awaiting debtor authentication), the MRTI must exactly match the MRTI of the in-flight request being cancelled. If not provided, Electrum handles this automatically by retrieving the MRTI of the in-flight transaction.
- Active mandate cancellation: If the mandate is already fully registered and active, a new, unique MRTI must be issued for the cancellation request. If not provided, Electrum determines the mandate state and applies the correct rule automatically.
Mandate Acceptance Report: The response echoes back the MRTI from the request being responded to. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.
Mandate Status Report: The status report echoes back the MRTI from the request being reported on. For API-level correlation, clients use originalMessageIdentifiers.messageIdentification instead.

Validation rules enforced by the scheme:

Must not be blank or spaces.
The bank number (positions 1–4) must be a valid, registered bank.
The date (positions 5–14) must be a valid calendar date.
Must conform to the 23-character structured format.
Must be unique at the time of request origination.

paymentScheme.schemeData.requestTransmissionNumberinteger(MandatePaymentSchemeRequestTransmissionNumber)[ 1 .. 4 ]

Sequence number for the message's transmission. Used exclusively for real-time (TT1/TT3) messages to track message retries. 1 = original message transmission, 2-4 = retries.

schemastringrequired

Value"MandateInitiationRequest"

{
  "messageIdentifiers": {
    "creationDateTime": "2019-08-24T14:15:22Z",
    "messageIdentification": "string"
  },
  "supplementaryData": {
    "property1": "string",
    "property2": "string"
  },
  "initiatingParty": {
    "address": { … },
    "contactDetails": { … },
    "countryOfResidence": "string",
    "identification": { … },
    "knownAsName": "string",
    "legalName": "string"
  },
  "instructedAgent": {
    "additionalIdentifications": [ … ],
    "address": { … },
    "bicfi": "string",
    "branch": { … },
    "clearingSystemMemberId": { … },
    "companyRegistration": "string",
    "lei": "string",
    "memberId": "string",
    "name": "string"
  },
  "instructingAgent": {
    "additionalIdentifications": [ … ],
    "address": { … },
    "bicfi": "string",
    "branch": { … },
    "clearingSystemMemberId": { … },
    "companyRegistration": "string",
    "lei": "string",
    "memberId": "string",
    "name": "string"
  },
  "mandate": {
    "adjustment": { … },
    "authentication": { … },
    "collectionAmount": { … },
    "creditor": { … },
    "creditorAccount": { … },
    "creditorAgent": { … },
    "creditorSchemeIdentification": { … },
    "debtor": { … },
    "debtorAccount": { … },
    "debtorAgent": { … },
    "firstCollectionAmount": { … },
    "mandateIdentification": "string",
    "mandateRequestIdentification": "string",
    "mandateStatus": { … },
    "maximumAmount": { … },
    "occurrences": { … },
    "reason": { … },
    "referredDocument": [ … ],
    "trackingIndicator": true,
    "type": { … },
    "ultimateCreditor": { … },
    "ultimateDebtor": { … }
  },
  "paymentScheme": {
    "schema": "ZA_RTC",
    "schemeData": { … }
  },
  "schema": "MandateInitiationRequest"
}

operational

Operations

bulk

Operations

accounts

Operations

account-verification

Operations