ID

UC-P-USCT-001

Name

Payment - Unconditional Social Cash Transfer

Description

The use case implements single scheduled electronic payment to beneficiaries of the programme, irrespective of whether it’s a one time or recurring payment

Verify payee account information prior to payment transaction

Trigger
(the event that triggers the use case)

Due date of payment has been reached

Preconditions
(list of conditions that MUST be met in order for the use case to be successful)

The payment building block enables different payment types.

The beneficiary has registered with the SRIS (Social Registry) system

The potential beneficiary’s needs have been assessed and required details captured

The beneficiary has been verified and enrolled into a programme

The beneficiary’s account details are known or knowable to the payment block. (this often includes a verification process within the payment building block) .

The repeating payment cycle has been scheduled

Note that some preconditions come from the other user journeys and use cases, see steps 2-5 of https://solutions.dial.community/use_cases/unconditional_social_cash_transf/use_case_steps/payment

Data inputs

Reference ID the the social registry programme (from the previous step in the user journey)

Payment due date

List of eligible beneficiaries

Payment amount for each eligible beneficiary

Payment account details for each eligible beneficiary

Actors
(a person, a company or organisation, a computer program, or a computer system - hardware, software, or both)

Clock/timer from scheduling building block

SRIS (social registry information system) screen flow

Payment building block

Workflow building block (for handling the overall process, computing payment amounts and scheduling payments)

Normal Course (what happens if the event is triggered and the preconditions have been met)

Workflow building block receives a trigger from the scheduling building block that the due date has been reached

Extract the beneficiary’s bank account details from the SRIS (Social Registry)

A workflow building block computes the payment amounts for the beneficiary

A workflow building block generates a transaction ID for the beneficiary

Request a payment for the beneficiary with the payment building block

Alternative Course
(links to other use cases in case there are different ways how to solve the same use case)

Add links to related use cases here, e.g. UC-P-USCT-002: Payment - Unconditional Social Cash Transfer (non-electronic/SMS payments)

UC-P-USCT-003: Payment - Unconditional Social Cash Transfer (direct payment based on family relationship)

If the user’s payments have failed, they can utilize the Registration - Unconditional Social Cash Transfer, see Logical process blueprint

Data output

The list of beneficiaries

IDs, alphanumeric code e.g. EE123456

PNO-EE37702272723

Names, e.g. Raul Carlson

Account numbers, alphanumeric

Amounts tied to the beneficiaries, decimal number e.g. 333.33

Process/session ID (reference to the audit trail record, e.g. 1231289371)

Transaction ID for each successful payment transaction, alphanumeric code, e.g. PAID123456290

Post-Conditions (the success criteria)

Payment response (as code) for each payment transaction

Transaction ID for each successful payment transaction

Each eligible beneficiary has been paid according to scheduled date

Audit trail of the process has been recorded

Exceptions
(error situations)

A payment has failed (e.g. due to missing/incorrect beneficiary bank account details and/or violating bank rules)

A payment has failed due to insufficient funds for withdrawal

Related BBs
(working groups related to that particular use case)

Payment BB - payment processing

Workflow BB - workflow management

Registries BB - data source for the use case

Information Mediator BB - providing interfaces

Security BB - supervision

Identity BB - no relation

Unconditional Social Cash Transfer

Target group

Social welfare staff

If a social cash transfer programme has enabled electronic payment processes (e.g. via banks, mobile money, etc.), payments are subsequently paid cyclically according to the programme schedule e.g. often bi-monthly. In the context where a digital financial service system is not employed, each beneficiary would be requested to travel to the nearest designated pay-point* and collect money by programme-specific authentication. In either case, the money is transferred to the selected payment provider or treasury as per generated payroll and is subsequently verified against the individual’s identification of program enrolment.

1. processing beneficiary payment directly to their account, or for generating payroll to deposit payment amounts for withdrawal by beneficiary from designated banking institution(s) / pay-point(s)

2. identifying and authenticating individual that is making a withdrawal, or to recall / verify deposit account information prior to payment transaction