Understand code values

Some JSON fields use a short code instead of a sentence. A code is an enum value: one value chosen from a fixed list. This page explains what each value means, where it is used, and whether it is currently accepted.

Codes are case-sensitive. Send CLRG, not clrg or Clearing. Reject a value that is absent from the documented list. Do not guess its meaning.

Know who chooses each value

Blinc sends the request. The institution validates the request and returns the response. Therefore,
most request codes are not values the institution chooses or replaces. The institution accepts a
supported value from Blinc or returns the documented rejection. The institution chooses only the
codes in its response.

There are no silent defaults. If a required field is missing, the institution must reject the
request; it must not insert a value. In the table below, standard value means the exact value used
for the normal documented flow. It does not mean "use this when the field is missing."

Field	Who sends it	Standard value for the documented flow	What the institution must do
`SttlmMtd`	Blinc	`CLRG`	Accept `CLRG` for the documented clearing flow. Accept another listed value only when onboarding explicitly enables it.
`ClrChanl`	Blinc	`RTNS` for Debit Authorization, Credit Transfer, and Reverse	Validate the value against the operation and the institution's onboarding configuration. Do not replace it.
`ChrgBr`	Blinc	`SLEV` for Debit Authorization and Credit Transfer	Validate it against the charge amount and settlement agreement.
`SeqTp`	Blinc	Debit Authorization: `OOFF`; Credit Transfer: `null`	Validate it against the operation. `null` is allowed only where the operation says the field is optional.
`Frqcy.Tp`	Blinc	Account Linking example: `MNTH`	Validate it against the customer consent. There is no universal frequency default.
`PaymentMethod`	Blinc	No universal value; it comes from the payment's initiating flow	Accept only the listed value that Blinc supplied. `DEFAULT` means no more specific channel classification was available; it is not permission to omit the field.
`CdtDbtInd`	Blinc	Credit Notification: `CRDT`	Reject `DBIT` on Credit Notification because that operation reports money entering the account.
`Ntry.Sts`	Blinc	Credit Notification: `BOOK`	Treat `PDNG` as not yet booked; do not report it as a completed credit.
Authentication fields	Blinc	`DEVICE_LOCAL_AUTH`, `DEVICE_BIOMETRIC_STRONG`, the hardware registered for the key, and `CUSTOMER`	Validate the complete combination and the positive numeric `key_id`. Do not manufacture missing authentication evidence.
Payment response `TxSts`	Institution	Success: `ACSC`; business rejection: `RJCT`	Return `ACSC` only after the operation is committed. Return `RJCT` with a reason code when it is not.
Account Linking response status	Institution	Success: `ACTV`	Return `ACTV` only after the account link has been created and can be used.
Account Unlinking response status	Institution	Success: `CANC`	Return `CANC` only after the account link can no longer be used.
Currency	Blinc	`NGN`	Validate `NGN` against the account and every related amount. Do not infer currency when it is missing.

Payment method

PaymentMethod says how the customer or sending party started the payment.

Value	Simple meaning	When to use it
`DEFAULT`	Blinc did not receive a more specific initiation-channel classification for this payment.	Accept only where the operation allows it. The canonical Credit Transfer example uses it. It does not mean that the JSON field may be omitted.
`STATICQR`	The customer scanned a QR code whose contents were prepared before this transaction.	Use when the QR code does not contain a newly generated transaction amount and reference. Validate the amount and merchant details supplied through the payment flow.
`DYNAMICQR`	The customer scanned a QR code generated for this transaction.	Use when the QR code contains transaction-specific values such as amount or reference.
`TAP2PAY`	The customer tapped a device or card-like credential at a supported terminal.	Use for the agreed contactless tap flow. Terminal details must match the payment.
`P2P`	A person-to-person or account-to-account flow without a merchant terminal.	Use when the payment was initiated directly between parties. Merchant fields may be absent only where the operation allows it.

Never send an empty string or a numeric enum position. DEFAULT is a public string value only for an operation that explicitly allows the fallback described above.

Settlement method

SttlmMtd says how the participating institutions settle the payment.

Value	Simple meaning	When to use it
`CLRG`	Settlement happens through the named clearing system.	Use when `ClrSys` and `ClrChanl` identify the agreed clearing route. This is the value used in the examples.
`INDA`	The institution receiving the instruction is responsible for settlement.	Use only when the onboarding agreement assigns settlement to the instructed institution.
`INGA`	The institution sending the instruction is responsible for settlement.	Use only when the onboarding agreement assigns settlement to the instructing institution.
`COVE`	Settlement uses a separate cover payment.	Use only when a separately agreed cover-payment flow exists. Do not use it for the normal clearing example.

The operation must use the settlement method agreed during onboarding. An institution must not switch methods because another value is technically recognised.

For the documented flow, Blinc sends CLRG. The institution validates it; the institution does not
return a settlement-method value in the response.

Clearing channel

ClrChanl says which clearing route carries the instruction.

Value	Simple meaning	When to use it
`RTGS`	Real-time gross settlement. Each payment settles separately.	Use only for an agreed gross-settlement route.
`RTNS`	Real-time net settlement. Payments are processed in real time and settled on a net basis.	Use for the agreed real-time net route shown in the examples.
`MPNS`	Mass-payment net settlement. A group of payments is settled on a net basis.	Use only for an agreed batch or mass-payment route.
`BOOK`	Book transfer inside one institution or ledger arrangement.	Use only when no external clearing movement is required and the onboarding agreement permits it.

ClrSys.Prtry names the clearing system. The examples use BLINC. This value identifies the agreed system; it is not a free-form description.

Core Switch currently sends RTNS for Debit Authorization, Credit Transfer, and Reverse. The
institution validates that value; it does not choose or replace the clearing channel. RTGS,
MPNS, and BOOK remain recognised meanings but are used only if a later onboarding agreement and
the sending implementation explicitly select them.

Charge bearer

ChrgBr says who bears transaction charges.

Value	Simple meaning	Required relationship
`CRED`	The creditor or beneficiary bears the charges.	The credited amount and charge details must show the deduction correctly.
`DEBT`	The debtor or sender bears the charges.	The debit and charge records must show that the sender pays the charge.
`SHAR`	Charges are shared between the parties.	Charge records must explain each party's part.
`SLEV`	Charges follow the rules of the selected service level.	Use only when the service-level agreement defines the charge treatment. This is the value used in the examples.

Core Switch currently sends SLEV for Debit Authorization and Credit Transfer. The institution
validates the supplied value and does not substitute another charge bearer.

Account link sequence type

SeqTp describes whether the debit authorization is one-off or recurring.

Value	Simple meaning	Rule
`FRST`	First collection in a repeating series.	Accept once at the start of a recurring account link.
`RCUR`	A normal repeating collection.	Use only when a separately agreed recurring-collection flow exists.
`FNAL`	Final collection in a repeating series.	Do not accept another recurring collection after the final one.
`OOFF`	One collection only.	The account link must not be used for another collection after success.

Debit Authorization uses OOFF for the agreed one-off authorization flow. Credit Transfer uses
null because collection sequencing does not apply. Do not turn a missing required value into
OOFF; reject it.

Account link frequency

Frqcy.Tp describes how often an account link expects collections.

Value	Simple meaning
`ADHO`	No fixed schedule. A collection occurs only when separately requested and allowed.
`DAIL`	Daily.
`WEEK`	Weekly.
`MNTH`	Monthly.
`YEAR`	Yearly.

Frequency does not by itself authorise a debit. The active account link, amount rules, date range, customer approval, and duplicate checks still apply.

The Account Linking example uses MNTH, but frequency comes from the customer's recorded consent.
There is no universal value the institution should assume.

Payment result status

The response status describes the business result. HTTP 200 does not replace it.

Value	Simple meaning	Is the action final?
`RCVD`	The instruction was received but has not passed later checks.	No.
`ACTC`	Basic technical checks passed.	No.
`ACFC`	Funds checks passed.	No, unless a separate operation rule says otherwise.
`ACSP`	Settlement is in progress.	No.
`ACWC`	Accepted with a documented change.	Only where the operation explicitly allows the change.
`ACSC`	Accepted and recorded or settled as required by the operation.	Yes for the documented success flows.
`ACCC`	Accepted and credited to the creditor.	Yes when the operation specifically uses this status.
`PDNG`	More processing is required.	No. Reconcile or wait for a later result.
`PART`	Only part of the instruction was accepted.	Not supported for full-only operations such as Reverse.
`ACWP`	Accepted without posting to the account.	Not a completed debit or credit. Use only when explicitly agreed.
`RJCT`	Rejected. Read the reason code and explanation.	Yes. No financial action must be reported as completed.
`CANC`	Cancelled.	Yes for the cancelled instruction or account link.
`BLCK`	Blocked from processing.	Yes until the blocking condition is resolved through the agreed process.

Operation pages state which statuses they allow. Do not return a technically known status where the operation permits only ACSC or RJCT.

For the current payment-operation responses, the institution returns ACSC after a completed
business action and RJCT when the action did not complete. No other status is a default.

Account-link status

Value	Simple meaning
`ACTV`	The account link is active and may be used when every other debit check passes.
`CANC`	The account link was cancelled and must reject later debits.
`SUSP`	The account link is temporarily unavailable.
`PNDG`	The link is not yet final. Do not treat it as active.
`EXPI`	The account link passed its end date or expiry rule.
`COMP`	The account link completed its permitted use, such as a completed one-off account link.

For a successful Account Linking response, the institution returns ACTV. For a successful Account
Unlinking response, it returns CANC. Do not return ACTV merely because the HTTP call succeeded.

Notification entry values

Field	Value	Simple meaning
`CdtDbtInd`	`CRDT`	The ledger entry adds money to the account. Credit Notification requires this value.
`CdtDbtInd`	`DBIT`	The ledger entry removes money. It is not accepted by Credit Notification.
`Sts`	`BOOK`	The credit entry is booked in the ledger.
`Sts`	`PDNG`	The credit entry is still pending. Do not report it as booked.

Credit Notification's documented completed-credit request uses CdtDbtInd: CRDT and Sts: BOOK.
Blinc sends both values. The institution validates them and does not convert PDNG to BOOK.

Authentication values

These fields describe the authentication already performed for Debit Authorization. They do not tell an institution how to authenticate a customer during Account Linking.

Authentication context

Value	Simple meaning	Current support
`DEVICE_LOCAL_AUTH`	The registered customer device made the authentication decision locally.	Accepted.
`PROXIMITY_BIOMETRIC`	Authentication used a nearby biometric interaction.	Reserved; reject for the current flow.
`DELEGATED`	Another party performed authentication for the customer.	Reserved; reject for the current flow.

Authentication type

Value	Simple meaning	Current support
`DEVICE_BIOMETRIC_STRONG`	The registered device completed its strong biometric check.	Accepted for the documented conformance example.
`DEVICE_PIN`	The registered device completed its device PIN check.	Accept only when explicitly enabled for the institution and consistent with the registered authenticator.

Authentication hardware

Value	Simple meaning
`SECURE_ENCLAVE`	The authenticator key is protected by the device's secure enclave.
`STRONGBOX`	The authenticator key is protected by Android StrongBox hardware.
`TRUSTED_EXECUTION_ENVIRONMENT`	The authenticator key is protected by a trusted execution environment.

Authentication actor

Value	Simple meaning	Current support
`CUSTOMER`	The account owner or customer performed the authentication.	Required for the documented device-local flow.
`DELEGATE`	Another person or service acted for the customer.	Reserved; reject for the current flow.

Missing, numeric, empty, Unknown, DEFAULT, or unrecognised authentication values must be rejected. The values must also form one consistent combination.

The complete standard combination is:

{
  "auth_context": "DEVICE_LOCAL_AUTH",
  "auth_type": "DEVICE_BIOMETRIC_STRONG",
  "auth_binding": {
    "hardware": "SECURE_ENCLAVE",
    "key_id": 42
  },
  "auth_actor": "CUSTOMER"
}

42 is an example only. Blinc sends the positive numeric database ID of the customer's registered
authenticator. The institution must look up that exact ID; it must never substitute 42, 0, or a
locally invented value.

Cancellation and Reverse reasons

Value	Simple meaning
`CUST`	The customer requested the cancellation or Reverse.
`DUPL`	The original instruction or account link was duplicated.
`TECH`	A technical problem requires the action.
`FRAD`	Fraud is suspected. Apply the institution's higher-risk controls.

Blinc sends the reason in the request. The Account Unlinking example uses CUST; the Reverse example
uses TECH. Neither is a silent default. Validate the reason that was actually supplied.

Remittance adjustment reasons

AdjstmntAmtAndRsn.Rsn explains why an invoice or referred-document amount changed. Blinc sends it
only when structured remittance contains an adjustment.

Value	Simple meaning	When it is valid
`COMM`	Commission was added or deducted.	The adjustment amount represents an agreed commission.
`COST`	A cost or expense changed the amount.	The supporting transaction or agreement identifies that cost.
`DISC`	A discount reduced the amount due.	The referenced document permits the discount.
`EARL`	An early-payment allowance reduced the amount.	The payment met the documented early-payment condition.
`PENF`	A penalty or fee changed the amount.	The referenced agreement permits that penalty or fee.
`TAX`	Tax changed the amount.	The tax treatment and amount can be reconciled.
`ADJS`	Another documented adjustment applies.	Use only when none of the more specific listed reasons fits; explain it in `AddtlInf`.
`CREN`	A credit note reduced the amount due.	The referenced credit note exists and reconciles with the adjustment.

There is no default adjustment reason. If there is no adjustment, omit the optional adjustment
object or send null as required by the operation schema.

Credit Notification is the one exception: its RmtInf.Strd.RfrdDocAmt.AdjstmntAmtAndRsn is
required, not optional, and Rsn must always equal PAYMENT_FACILITATOR; none of the codes
above apply there. It carries FeeBreakdown.PaymentFacilitatorShare (amount, currency, and
institution identity), never a discount or invoice adjustment. A zero payment-facilitator share
must still be sent explicitly with Rsn set to PAYMENT_FACILITATOR, not omitted. See
Credit Notification.

Identifier schemes

Value	Simple meaning
`NUBAN`	The value is a Nigerian Uniform Bank Account Number.
`BVN`	The value is a Bank Verification Number. Treat it as sensitive identity data.
`BLINC`	The value is an identifier assigned or recognised within the Blinc contract, such as a creditor identifier or clearing-system name.
`OTHR`	No more specific documented category code applies. It does not permit an undocumented value in another field.

Currency

The current examples use NGN, Nigerian naira. Send currency as a three-letter uppercase code. The value must match the account, instructed amount, settlement amount, charges, and original transaction where those fields apply. Never send DEFAULT or a numeric enum position.

For the current contract, NGN is the only documented currency value. Blinc sends it and the
institution validates it. A missing currency must be rejected; it must not be silently set to NGN.

Rejection reason codes

The rejection codes used by this contract, including MD01, RC01, AG01, DUPL, NOOR, AM09, and AM11, are explained in Return clear errors and handle repeated deliveries. That page tells the institution when to return each code; the institution does not call or retry a Blinc operation endpoint.

Build the first operation in the customer journey: Account Linking.