Payments Academy
Business rules PAYMENT OPERATIONS STARTED LIVE 01 Business rules - conditions that decide how a payment ACTIVE 02 Cut-off times - most common source of customer complaints QUEUED 03 Value dating rules - determine the date from which interest QUEUED 04 Charge rules decide - payment and how the charge is calculated. QUEUED 05 Validation rules - checks a payment must pass before it is released QUEUED 06 Rule table - analyst's main tool for documenting all QUEUED Business rules are the conditions that decide how a payment is processed, and in payments they are numerous, precise and often invisible until one of them is broken. Step 1 of 6 Business rules STARTED Business rules conditions that decide how a payment ACTIVE Cut-off times most common source of customer complaints QUEUED Value dating rules determine the date from which interest QUEUED Charge rules decide payment and how the charge is calculated. QUEUED Validation rules checks a payment must pass before it is QUEUED Rule table analyst's main tool for documenting all QUEUED Business rules are the conditions that decide how a payment is processed, and in payments they are numerous, precise and often invisible until one of them is broken.
Cut-off times PAYMENT OPERATIONS IN PROGRESS LIVE 01 Business rules - conditions that decide how a payment DONE 02 Cut-off times - most common source of customer complaints ACTIVE 03 Value dating rules - determine the date from which interest QUEUED 04 Charge rules decide - payment and how the charge is calculated. QUEUED 05 Validation rules - checks a payment must pass before it is released QUEUED 06 Rule table - analyst's main tool for documenting all QUEUED Cut-off times are the most common source of customer complaints, so they must be documented with complete precision. Step 2 of 6 Cut-off times IN PROGRESS Business rules conditions that decide how a payment DONE Cut-off times most common source of customer complaints ACTIVE Value dating rules determine the date from which interest QUEUED Charge rules decide payment and how the charge is calculated. QUEUED Validation rules checks a payment must pass before it is QUEUED Rule table analyst's main tool for documenting all QUEUED Cut-off times are the most common source of customer complaints, so they must be documented with complete precision.
Value dating rules PAYMENT OPERATIONS IN PROGRESS LIVE 01 Business rules - conditions that decide how a payment DONE 02 Cut-off times - most common source of customer complaints DONE 03 Value dating rules - determine the date from which interest ACTIVE 04 Charge rules decide - payment and how the charge is calculated. QUEUED 05 Validation rules - checks a payment must pass before it is released QUEUED 06 Rule table - analyst's main tool for documenting all QUEUED Value dating rules determine the date from which interest is calculated on the payment. Step 3 of 6 Value dating rules IN PROGRESS Business rules conditions that decide how a payment DONE Cut-off times most common source of customer complaints DONE Value dating rules determine the date from which interest ACTIVE Charge rules decide payment and how the charge is calculated. QUEUED Validation rules checks a payment must pass before it is QUEUED Rule table analyst's main tool for documenting all QUEUED Value dating rules determine the date from which interest is calculated on the payment.
Charge rules decide who bears cost PAYMENT OPERATIONS IN PROGRESS LIVE 01 Business rules - conditions that decide how a payment DONE 02 Cut-off times - most common source of customer complaints DONE 03 Value dating rules - determine the date from which interest DONE 04 Charge rules decide - payment and how the charge is calculated. ACTIVE 05 Validation rules - checks a payment must pass before it is released QUEUED 06 Rule table - analyst's main tool for documenting all QUEUED Charge rules decide who bears the cost of a payment and how the charge is calculated. Step 4 of 6 Charge rules decide who bears cost IN PROGRESS Business rules conditions that decide how a payment DONE Cut-off times most common source of customer complaints DONE Value dating rules determine the date from which interest DONE Charge rules decide payment and how the charge is calculated. ACTIVE Validation rules checks a payment must pass before it is QUEUED Rule table analyst's main tool for documenting all QUEUED Charge rules decide who bears the cost of a payment and how the charge is calculated.
Validation rules PAYMENT OPERATIONS IN PROGRESS LIVE 01 Business rules - conditions that decide how a payment DONE 02 Cut-off times - most common source of customer complaints DONE 03 Value dating rules - determine the date from which interest DONE 04 Charge rules decide - payment and how the charge is calculated. DONE 05 Validation rules - checks a payment must pass before it is released ACTIVE 06 Rule table - analyst's main tool for documenting all QUEUED Validation rules are the checks a payment must pass before it is released, and each one needs an exact error message. Step 5 of 6 Validation rules IN PROGRESS Business rules conditions that decide how a payment DONE Cut-off times most common source of customer complaints DONE Value dating rules determine the date from which interest DONE Charge rules decide payment and how the charge is calculated. DONE Validation rules checks a payment must pass before it is ACTIVE Rule table analyst's main tool for documenting all QUEUED Validation rules are the checks a payment must pass before it is released, and each one needs an exact error message.
Rule table PAYMENT OPERATIONS COMPLETE LIVE 01 Business rules - conditions that decide how a payment DONE 02 Cut-off times - most common source of customer complaints DONE 03 Value dating rules - determine the date from which interest DONE 04 Charge rules decide - payment and how the charge is calculated. DONE 05 Validation rules - checks a payment must pass before it is released DONE 06 Rule table - analyst's main tool for documenting all ACTIVE The rule table is the analyst's main tool for documenting all of this. Step 6 of 6 Rule table COMPLETE Business rules conditions that decide how a payment DONE Cut-off times most common source of customer complaints DONE Value dating rules determine the date from which interest DONE Charge rules decide payment and how the charge is calculated. DONE Validation rules checks a payment must pass before it is DONE Rule table analyst's main tool for documenting all ACTIVE The rule table is the analyst's main tool for documenting all of this.

Key points of this lesson, in order.

0:00 / 3:32 Step 1 of 6

Business Rules and Processing Conditions

BA Practical Workshop, Lesson 3 of 7, Narration 3:32, D14 Business analysis and professional practice

Value datingPurpose codeValue date

What you will learn

Your objective. By the end of this lesson, you will be able to explain business rules and processing conditions. Business rules are the conditions that decide how a payment is processed, and in payments they are numerous, precise and often invisible until one of them is broken.

Why it matters. The analyst's job is to find every rule, write it down in plain language, and make sure the system enforces it exactly.

Chapter objective: Learner applies business analysis techniques to a payments project, writing requirements, user stories, acceptance criteria, and a traceability matrix for a real payment feature. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Business rules
  • Cut-off times
  • Value dating rules
  • Charge rules decide who bears cost
  • Validation rules
  • Rule table

Key terms

Value dating: The practice of assigning a value date to a payment, which is the date funds become available and interest starts.

Purpose code: A code that states the commercial reason for a payment, such as supplier payment, salary or goods. Purpose codes are taken from an ISO external code list and support regulatory reporting, screening...

Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.

Clearing and settlement timeline showing Business Rules and Processing Conditions.

Practise this lesson

Exercise

Work out what the beneficiary receives for a 500 rupees payment under OUR, SHA and BEN.

Use the charge arrangement rules in this lesson and the correspondent and beneficiary bank fees named in the lesson.

  1. What to do. Calculate the amount credited under each of the three arrangements and state who pays each fee.

Correct result. Under OUR the sender pays all charges and the beneficiary receives the full amount. Under SHA the sender pays the sending charges and the beneficiary pays the receiving charges. Under BEN the beneficiary pays all charges and receives the amount less all fees.

Why. The charge arrangement decides who pays and how much arrives. A customer who was promised the full amount and receives less will complain, and the complaint lands on the analyst.

Check your understanding

Practice question

A developer asks the BA for the mapping between the ISO 20022 pacs.008 fields and the internal payment record. The BA has no mapping document. What should the BA produce?

Takeaway and next step

What to remember

When a rule changes, the table is updated and versioned, so the team always works from one agreed source of truth.

Map the message fields from this lesson in the mapping workbench.

Open the Mapping Workbench →

Builds on "Business Process Modelling: As-Is and To-Be Flows".

Transcript and full text

Show transcript

Business rules are the conditions that decide how a payment is processed, and in payments they are numerous, precise and often invisible until one of them is broken. A cut-off time rule decides whether a payment is processed today or tomorrow. A value dating rule decides which date the beneficiary's account is credited. A charge rule decides who pays the fees and how much. A validation rule decides whether a payment is accepted or rejected. The analyst's job is to find every rule, write it down in plain language, and make sure the system enforces it exactly. Cut-off times are the most common source of customer complaints, so they must be documented with complete precision. A rule might state that outward remittances received before 3 in the afternoon Indian Standard Time are processed the same day, while those received after 3 in the afternoon are processed the next working day. The rule must also say what counts as received, whether it is the moment the customer submits the instruction or the moment it passes validation, and what happens on a bank holiday. A payment submitted at five past 3 in the afternoon on a Friday before a Monday holiday is value dated Tuesday, and the customer must be told that at the point of submission. Value dating rules determine the date from which interest is calculated on the payment. For a domestic transfer the value date is usually the same as the processing date, but for a cross-border payment it depends on the currency, the destination and the correspondent bank's calendar. A US dollar payment sent from Mumbai to New York on a Friday is typically value dated Monday, because Saturday and Sunday are not business days in the United States. The analyst documents these rules in a table by currency and corridor, because a developer cannot derive them from a single sentence. Charge rules decide who bears the cost of a payment and how the charge is calculated. In SWIFT payments the field 71A carries the charge code. OUR means the sender pays all charges, BEN means the beneficiary pays them, and SHA means the charges are shared. A bank might charge a flat 500 rupees for an outward remittance up to 100,000 rupees and 0.1 percent above that, with a minimum of 750 rupees. The rule table must state the charge for every band, the currency of the charge, and whether the charge is deducted from the payment amount or debited separately. Validation rules are the checks a payment must pass before it is released, and each one needs an exact error message. A validation might require that the beneficiary account number is exactly 34 characters for an IBAN, that the amount is greater than zero and not more than 10,000,000 rupees, and that the purpose code is one of the approved values such as P0101 for export of goods. If a rule fails, the system must reject the payment with a clear message such as beneficiary account number is not a valid IBAN, rather than a generic error, so that operations can fix the problem without guessing. The rule table is the analyst's main tool for documenting all of this. Each row has a rule identifier such as BR-001, a plain language description, the condition that triggers it, the action the system must take, and the source of the rule, which might be a central bank regulation, an internal policy or a scheme rule. The table is reviewed with business, operations and compliance, and every row is signed off. When a rule changes, the table is updated and versioned, so the team always works from one agreed source of truth.

Business rules are the conditions that decide how a payment is processed, and in payments they are numerous, precise and often invisible until one of them is broken. A cut-off time rule decides whether a payment is processed today or tomorrow. A value dating rule decides which date the beneficiary's account is credited. A charge rule decides who pays the fees and how much. A validation rule decides whether a payment is accepted or rejected. The analyst's job is to find every rule, write it down in plain language, and make sure the system enforces it exactly.

Cut-off times are the most common source of customer complaints, so they must be documented with complete precision. A rule might state that outward remittances received before 3 in the afternoon Indian Standard Time are processed the same day, while those received after 3 in the afternoon are processed the next working day. The rule must also say what counts as received, whether it is the moment the customer submits the instruction or the moment it passes validation, and what happens on a bank holiday. A payment submitted at five past 3 in the afternoon on a Friday before a Monday holiday is value dated Tuesday, and the customer must be told that at the point of submission.

Value dating rules determine the date from which interest is calculated on the payment. For a domestic transfer the value date is usually the same as the processing date, but for a cross-border payment it depends on the currency, the destination and the correspondent bank's calendar. A US dollar payment sent from Mumbai to New York on a Friday is typically value dated Monday, because Saturday and Sunday are not business days in the United States. The analyst documents these rules in a table by currency and corridor, because a developer cannot derive them from a single sentence.

Charge rules decide who bears the cost of a payment and how the charge is calculated. In SWIFT payments the field 71A carries the charge code. OUR means the sender pays all charges, BEN means the beneficiary pays them, and SHA means the charges are shared. A bank might charge a flat 500 rupees for an outward remittance up to 100,000 rupees and 0.1 percent above that, with a minimum of 750 rupees. The rule table must state the charge for every band, the currency of the charge, and whether the charge is deducted from the payment amount or debited separately.

Validation rules are the checks a payment must pass before it is released, and each one needs an exact error message. A validation might require that the beneficiary account number is exactly 34 characters for an IBAN, that the amount is greater than zero and not more than 10,000,000 rupees, and that the purpose code is one of the approved values such as P0101 for export of goods. If a rule fails, the system must reject the payment with a clear message such as beneficiary account number is not a valid IBAN, rather than a generic error, so that operations can fix the problem without guessing.

The rule table is the analyst's main tool for documenting all of this. Each row has a rule identifier such as BR-001, a plain language description, the condition that triggers it, the action the system must take, and the source of the rule, which might be a central bank regulation, an internal policy or a scheme rule. The table is reviewed with business, operations and compliance, and every row is signed off. When a rule changes, the table is updated and versioned, so the team always works from one agreed source of truth.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.