Decoding Transfer Fields: Remark, Purpose, Customer & Bank Notes for FinTech Developers

1

Basic Business Concepts

Business concepts and their relationships

In transfer transactions the most frequently mixed fields are remark, purpose, customer note, bank note, and summary. Understanding each term prevents confusion for developers handling loosely specified requirements.

Remark refers to the bank note, which the bank uses internally as a reminder.

Summary is the customer note, used by the payer to remind the payee.

Purpose is the payer's own reminder about the transaction.

In short:

Remark = Bank note

Summary = Customer note

Public-to-Private (salary disbursement and similar businesses)

Personal transfers are relatively simple, but public-to-private scenarios introduce complexity, especially regarding purpose and summary.

For payroll disbursement, banks often provide a fixed list of purposes such as salary, performance salary, bonus, allowance, reimbursement, service fee, labor fee, commission, etc.

During a transfer, the purpose combines with remark to form the "recipient customer note" displayed on the bank receipt; if remark is empty, the purpose alone is used.

Some staffing agencies batch‑process payroll for many companies and need to distinguish payer notes from recipient notes, leading to custom processing rules.

Typical rule example: recipient note = purpose + single‑transaction remark.

Disbursement companies may customize their receipts as purpose + document‑page remark.

An example is China Merchants Bank's "Salary Pass" service, which adds a "disbursement description" field to label the batch; this field appears in detail queries.

The statement also includes a "disbursement type" attribute with values like salary, bonus, allowance, welfare, reimbursement, demolition compensation, funds, pension, labor fee, scholarship, etc., or custom values, usually selected from the "purpose" field on the disbursement form.

2

Design Model

When designing a disbursement model, the key elements to consider are purpose, remark, and disbursement description.

Because different clients may have varying rules for recipient notes, payer notes, and disbursement‑type fields, the model must expose flexible interfaces and processing modes.

The design is relatively straightforward since the total set of elements is limited; combinations are typically achieved by concatenating fields.

The main challenge lies in a detailed understanding of the business fields themselves.