Skip to main content
PayFi creates one Analysis job per uploaded document. The private worker downloads the object from storage, sends operation metadata and file bytes into the Analysis pipeline, validates the typed response, and stores a redacted result. Analysis output can move an operation to human review or request more partner action. It never approves an operation automatically.

Processing contract

Each analysis run receives:
  • Operation identifiers: operationId, partnerOperationId, and organization scope.
  • The approved initial document requirement context: requirementsAssessmentId, approved document types, policy version, and redacted context summary.
  • Declared operation metadata: nature, amount, currency, settlement date, and description.
  • Customer metadata when provided: legal name, masked tax ID, CNAE, and partner customer ID.
  • Document metadata: declared document type, document ID, file name, content type, size, storage key, and upload session.
  • File bytes read privately by the worker.
Each analysis run returns a strict contract-v2 result. Unknown fields or an invalid payload fail schema validation; they are not silently removed. The result includes:
  • schemaVersion, analysisRunId, analysisOutcome, qualityStatus, and analysisMode.
  • The original 22 requested fields plus beneficiary, account number, economic owner, and evidence-backed nature code, each with FOUND, NOT_FOUND, UNCERTAIN, or CONFLICT status.
  • Confidence and evidence per field: document, page, bounding box when available, redacted excerpt, excerpt hash, and source/version metadata.
  • Completeness result against the approved document requirement list. The final analysis does not invent a default document list.
  • Content validation flags deduplicated by reason code, field, and evidence.
  • ICC / trade-finance checks.
  • CNAE and operation nature result.
  • Fraud and duplicate signals.
  • e-CAM C212 draft fields.
  • Deterministic score breakdown, reason codes, impact, short explanation, and risk level. Scores remain unset when the engine must abstain.
  • Recommended next status.
  • analysisDisposition, plus the immutable workflow, model, prompt, rules, partner-policy, regulatory-corpus, OCR, and RegDocs provenance snapshot.
The backend validates the final Analysis response before persisting it. Invalid or unparseable output, unavailable critical source, empty OCR, or low-confidence critical evidence produces PARTIAL, HUMAN_REVIEW_REQUIRED, TECHNICAL_FAILURE, or POLICY_NOT_CONFIGURED. It never produces a ready result.

Persistence model

PayFi stores both a normalized projection and a redacted analysis record for each processed document. The normalized projection powers partner operation status, webhooks, filtering, and human review. It includes score, risk level, missing document types, document status, latest job status, and technical job error when a job fails. The redacted analysis record preserves the typed Analysis response after redaction. It is intentionally not an unrestricted 1:1 copy of every internal workflow field: raw documents, prompts, completions, credentials, presigned URLs, signatures, full tax IDs, and internal traces are not returned through public APIs. Timeline events persist only scoped IDs, stage, status, duration, and version metadata; raw input/output/error payloads, original file names, hashes, and PII are not written for new v2 events. Documentary risk and technical failure are separate:
  • PROCESSED + SUCCEEDED + low score or critical flags means the pipeline completed and found documentary risk.
  • PROCESSING_FAILED + FAILED_FINAL means the pipeline could not produce a valid analysis result after retries.
Deterministic checks are authoritative. If the detected type differs from the declared type, PayFi records a type-mismatch signal with evidence. If that detected type does not satisfy the approved required document list, PayFi returns the missing required type in missingDocumentTypes and moves the operation to ACTION_REQUIRED. A scan or missing metadata alone is informational and is not treated as fraud.

Processing stages

Operational outcomes

READY_FOR_MANUAL_REVIEW means the latest Decision Pack is current, complete, VALID, and has no critical blocker. It gives a human reviewer the option to approve, reject, or request changes. ACTION_REQUIRED means PayFi needs more partner/client action before a reviewer should make a final decision. Common causes are missing mandatory documents, malformed bank details, unparseable scans, unsupported document types, or contradictions that require a corrected document. PROCESSING_FAILED means the pipeline could not produce a valid result after retries. REVIEW_REQUIRED, INVALID, and DEGRADED outcomes cannot be approved; the reviewer can reject or request changes. Reprocessing invalidates older packs and is idempotent for the same input snapshot.

Why manual approval remains required

The product goal discussed with prospective partners is to increase analyst productivity and reduce fraud risk, not to remove the human approval obligation. Analysis should make the review faster by preparing the evidence and score. It should not be the final approver for regulated FX operations.