Recipient RFI Overview

An RFI (Request for Information) is a compliance case used to collect supporting information. Each RFI case is a standalone resource with its own case_id, lifecycle, requirements, submissions, and webhook events.

This guide covers RFI cases whose subject is a recipient. Some recipients are created with status pending_review and go through compliance review before they can receive payments. When 1Money needs supporting information about a recipient, usually during that review but also after approval, we open an RFI case with the recipient as the case subject. Cases about a transaction are documented in the Transaction RFI Overview; both kinds use the same endpoints and the same submission rules.

A recipient RFI case and the recipient itself have independent statuses. The case tells you what information we need; the recipient's status tells you whether it can be paid. Check each separately to get the most up-to-date picture.

Compared with Transaction RFI

Recipient RFI reuses the transaction RFI integration. The case resource, the submission endpoint, the TEXT and FILE rules, and the request signing are unchanged. The table lists what differs and, in the last column, what an existing transaction RFI integration needs to change.

The rest of this page describes the full flow for integrations that start from scratch.

Understand case and each requirement status

An RFI case has an overall status, and each requirement inside it has its own status. Use the case status to understand where the review stands. Use the requirement status to decide which specific items need a response.

Case status

Once we receive everything requested in the current round, the case moves to ANSWERED automatically. You do not need to call a separate endpoint to submit or complete the case.

The RFI decision does not, by itself, tell you whether the recipient was approved. Always read the recipient's status, or wait for recipient.approved or recipient.rejected, for its final outcome.

Requirement status

Each requirement has a stable requirement_id for correlation. Do not send that ID in a submission path or body; submit your response to the case, and 1Money matches it to the requirement. The case API returns the current evidence for each requirement, not its full submission history.

Respond to recipient RFI cases

Recipient RFI cases are opened by 1Money only. Unlike transactions, there is no proactive submission and no requirement preview for recipients, so this is the only flow you need to integrate.

Step 1 - Set up your notification method

You need a way to know when a case needs your attention. You can use either webhooks or polling:

• Webhooks — strongly recommended: we notify you when the case changes, and you retrieve the latest case.
• Polling: your system periodically checks for cases that need a response.

Use webhooks whenever your system can receive them. They let you respond sooner and avoid unnecessary API calls. Even with webhooks, run a slower polling job as a safety net in case a delivery is missed.

Webhook integration — strongly recommended

Subscribe to these events:

Each webhook tells you which case and recipient changed:

• resource.type=rfi_cases and resource.id={case_id} identify the case.
• data.subject.type=RECIPIENT and data.subject.id={recipient_id} identify the related recipient.

The webhook only tells you that something changed. It does not contain the complete case information. When you receive one:

1. Verify the webhook and make sure you have not already processed it.
2. Read the case_id from resource.id.
3. Retrieve the latest case from GET /v1/customers/{customer_id}/rfi-cases/{case_id}.
4. Check rfi_status and each item in requirements to decide what to do next.

Payload examples for each event are in Recipient RFI Webhooks.

Polling and recovery checks

If your system cannot receive webhooks, poll the list endpoint for recipient cases that need a response:

GET /v1/customers/{customer_id}/rfi-cases?subject_type=RECIPIENT&action_required=true&page=1&size=100

Even if you use webhooks, run this request periodically to catch anything you may have missed. To catch up on all case changes since your last successful check, use updated_from:

GET /v1/customers/{customer_id}/rfi-cases?subject_type=RECIPIENT&updated_from={ISO_8601_UTC}&page=1&size=100

The updated_from filter includes cases updated at the exact timestamp you provide. This means the last case from one check may appear again in the next. Read every page, and use case_id and updated_at to avoid processing that boundary case twice.

Omit subject_type to receive transaction and recipient cases in one list; subject.type on each item tells them apart.

Step 2 - Create the recipient

Create the recipient through the usual Recipients API and save its recipient_id. A recipient that needs compliance review is returned with status pending_review.

Every response from the Recipients API (get, list, update, create, get by idempotency key) carries an action_required field. It is null when nothing is needed from you, and always null on the create response because a case cannot exist yet. Once we open an RFI case and need a response, it points to the case:

{
  "recipient_id": "550e8400-e29b-41d4-a716-446655440000",
  "customer_id": "14f20ebd-893b-11f0-b308-2eaa4f6974f2",
  "business_type": "COMPANY",
  "full_name": "Acme Software Inc",
  "relationship": "VENDOR",
  "status": "pending_review",
  "action_required": {
    "type": "RFI",
    "case_id": "TC-3N7Q-D2KV",
    "action": "SUBMIT_INFORMATION"
  },
  "created_at": "2026-09-23T08:02:11.402Z",
  "modified_at": "2026-09-23T08:15:42.118Z"
}

If you already read recipients regularly, action_required is a third way to notice an open case. It goes back to null once we have received everything requested in the current round, while the case itself stays open under review.

Step 3 - Receive the case notification

If you use webhooks, wait for rfi.recipient.action_required. If you use polling, list cases with subject_type=RECIPIENT&action_required=true. Either way, retrieve the case:

GET /v1/customers/{customer_id}/rfi-cases/{case_id}

Example response:

{
  "case_id": "TC-3N7Q-D2KV",
  "case_class": "RECIPIENT",
  "rfi_status": "ACTION_REQUIRED",
  "subject": {
    "type": "RECIPIENT",
    "id": "550e8400-e29b-41d4-a716-446655440000"
  },
  "requirements": [
    {
      "requirement_id": "RQ-5K2P-M8WD",
      "type": "TEXT",
      "accepted_document_types": [],
      "required": true,
      "status": "ACTION_REQUIRED",
      "note": "Please describe your business relationship with this recipient.",
      "submissions": []
    },
    {
      "requirement_id": "RQ-9F4C-T2LN",
      "type": "FILE",
      "accepted_document_types": [
        "STANDARD_RECIPIENT_INFORMATION"
      ],
      "required": true,
      "status": "ACTION_REQUIRED",
      "note": "Please provide the signed agreement with this recipient.",
      "submissions": []
    }
  ],
  "created_at": "2026-09-23T08:15:42.118+00:00",
  "updated_at": "2026-09-23T08:15:42.118+00:00"
}

There are two requirements here: one TEXT and one FILE. subject.id is the recipient_id; a recipient subject has no transaction_type, and case_class is RECIPIENT.

Step 4 - Send the requested information

If the case asks for a TEXT response, send the requested explanation:

POST /v1/customers/{customer_id}/rfi-cases/{case_id}/submissions
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
Content-Type: application/json

{
  "type": "TEXT",
  "text": "Acme Software Inc is our payroll software vendor under a two-year contract."
}

If the case asks for a FILE, send multipart/form-data with these parts:

Include a new UUID in the Idempotency-Key header for each new response.

FILE requests use multipart-specific HMAC signing. Use complete-body signing when your client exposes the final encoded bytes, or native form-data signing with UNSIGNED-PAYLOAD when it does not. See Signing multipart requests for the canonical strings, security properties, Postman script, and language examples.

Retrieve the case again after each response. One response may complete one requirement while others still need your attention.

Step 5 - Continue listening to the webhook for any case status update

After we receive everything requested in the current round, the case moves to ANSWERED and we send rfi.recipient.answered to mark that all requirements are addressed. The recipient's action_required is null again.

ANSWERED does not mean that the review is finished. It means we have what we need for now and 1Money compliance will review the case. If during the review we request additional information, the case returns to ACTION_REQUIRED and you will receive another rfi.recipient.action_required.

Step 6 - Wait for the recipient outcome

The recipient's approval or rejection is a separate decision from the RFI case. Keep listening for recipient.approved or recipient.rejected (see Recipient webhooks), or read the recipient's status, which becomes success or blocked.

The recipient can be approved while its case is still ANSWERED; the case is closed by 1Money when the review is complete. Do not use rfi_status to decide whether the recipient can be paid, and do not use the recipient's status to decide whether the RFI is finished. Once the recipient is rejected, further RFI responses do not change its outcome.

RFI endpoints

When all currently requested information has been received, the case automatically enters ANSWERED; no separate submit action is required. Webhook payloads are in Recipient RFI Webhooks.

Submission requirements

The same validation rules apply to transaction and recipient cases:

For FILE responses:

• Keep the note within 1,000 characters.
• Include a filename of no more than 255 characters.
• Upload no more than 10 MB.
• Use pdf, jpeg, jpg, png, csv, xls, or xlsx.
• Make sure the filename extension matches the file content.
• Send the original file bytes; do not Base64-encode the file or wrap it in a data URI.

When we request a FILE, choose one value from the requirement's accepted_document_types and send it as the submission's document_type. You may send other supporting files, but they do not complete a requirement unless their document_type is accepted by that requirement.

For HMAC-authenticated FILE requests, follow Signing multipart requests.

Supported document_type values

Recipient cases use their own list of values, separate from the transaction list. Choose the value that best describes what you are sending; the FILE requirement's accepted_document_types tells you which values complete it. A document_type outside this list is rejected on a recipient case.

Related guides

• Recipient RFI Webhooks explains each rfi.recipient.* event with payload examples and how to recover missed or repeated deliveries.
• Recipient webhooks covers recipient.approved and recipient.rejected.
• Transaction RFI Overview covers cases whose subject is a transaction, including proactive submission and requirement preview.
• Signing multipart requests explains both FILE signing modes and includes Postman and language examples.
• Authentication explains sandbox bearer tokens and production HMAC authentication.
• Recipients explains how recipients and their bank accounts are created.