Skip to content

PH-06 — Payment Policy and Risk Decisioning

Payment Hub · Working Draft · Revised Working Copy v5 · Updated September 3, 2026

1. Objective

Provide shared policy and decisioning used by DragonPay Payment Products to determine whether payment processing may proceed, must stop, requires additional action, or requires review.

PH-06 provides a consistent decisioning capability across Products while allowing each Tenant, Product, and use case to apply the policies appropriate to that payment context.

PH-06 establishes:

  • configurable policy by Tenant, Product, and use case;
  • deterministic evaluation of approved eligibility, limit, velocity, validation, authentication, external-risk, and other supported rules;
  • durable, explainable Decisions with normalized outcomes and reasons;
  • preservation of the policy version and evidence used for each Decision;
  • safe enforcement of limits and velocity under concurrent payment activity;
  • consumption of CU/provider fraud or risk results when applicable;
  • re-evaluation when materially relevant payment facts or evidence change;
  • controlled operational overrides without rewriting the original automated Decision; and
  • current Decision retrieval for PH-04 workflow progression and applicable PH-07 route constraints.

The initial Product does not require DragonPay to produce its own universal numeric Risk Score or Risk Level.

A future Product or integration may introduce DragonPay-generated scoring, or consume external provider scores, when there is a demonstrated business need.

The exact rules engine architecture, persistence schema, rule-handler implementation, concurrency mechanism, API shape, decision-processing sequence, scoring model, and external-provider integration are Engineering decisions provided the requirements in this epic are preserved.

2. Ownership boundaries

Owner Responsibility
Payment Product epics Define when policy evaluation is required and which Product behavior follows each Decision outcome.
PH-01 Authorization for policy administration, overrides, and applicable administrative audit.
PH-02 Product configuration that may affect Product-specific policy behavior.
PH-03 Canonical payment facts and identifiers evaluated by policy.
PH-04 Requests evaluation at Product-defined points and uses the current Decision to progress, wait, stop, or request further action.
PH-05 Current Party, Payment Instrument, relationship, authority, and validation facts.
PH-06 Policy configuration, evaluation, immutable Decisions, reasons, external-risk evidence, limits/velocity decisioning, and overrides.
PH-07 Route eligibility and selection; consumes PH-06 route constraints when policy produces them.
PH-11 Case/review workflow when a Product requires manual investigation.
PH-13 Operational/reporting views derived from PH-06 outcomes and evidence.

PH-06 determines policy outcome. It does not execute payment movement, select a route, or own the payment lifecycle.

3. Decision model

Every successful PH-06 evaluation produces one immutable Decision.

Initial normalized Decision outcomes are:

  • APPROVE — applicable policy permits the evaluated payment action to proceed.
  • REJECT — applicable policy does not permit the evaluated action.
  • ACTION_REQUIRED — additional customer, Product, validation, authentication, or other action is required before proceeding.
  • REVIEW_REQUIRED — the payment requires authorized operational/manual review before proceeding.
  • UNAVAILABLE — required decisioning evidence or an external decision source is unavailable and policy does not permit approval without it.
  • ERROR — the evaluation could not be completed safely.

When multiple applicable policy rules produce different Decision effects for the same evaluation, the applicable policy must resolve them to exactly one deterministic Decision outcome.

A Decision also retains normalized reasons explaining the outcome.

The owning Product determines what each outcome means for its workflow. PH-06 does not automatically convert ACTION_REQUIRED, REVIEW_REQUIRED, UNAVAILABLE, or ERROR into approval.

Risk information

Risk and fraud information may be one input into policy decisioning.

When a CU, processor, or risk provider supplies:

  • a score;
  • risk level;
  • fraud result;
  • recommendation; or
  • reason,

PH-06 preserves the source result and makes the applicable normalized result available to policy evaluation and operations.

The initial Product does not require DragonPay to synthesize those inputs into its own 0-100 score.

4. Policy model

A Policy defines the approved rules and parameters used for one Tenant, Product, and applicable use case.

DragonPay must support:

  • preparation/editing of policy before publication;
  • validation of policy configuration before it may govern payment processing;
  • publication of an immutable policy version;
  • selection of the current published policy for new evaluations;
  • retention of prior published versions so historical Decisions remain explainable; and
  • controlled retirement/replacement of policy versions.

A Decision remains associated with the exact policy version used for that evaluation.

Changing policy does not rewrite a prior Decision.

Approved rule model

Policy configuration may select and configure DragonPay-supported rule types and parameters.

Policy administration must not permit arbitrary executable code supplied by a Tenant or administrator.

Initial rule categories may include:

  • eligibility;
  • transaction amount limits;
  • payment-count velocity;
  • payment-amount velocity;
  • Party/Payment Instrument validation requirements;
  • authentication/assurance requirements;
  • counterparty/payment-history conditions;
  • external fraud/risk outcomes;
  • data/evidence freshness requirements; and
  • Product-specific policy rules required by an implemented Product.

The actual rules implemented should be driven by supported Product/CU needs rather than by creating a generalized rules platform in advance.

5. Evaluation context

PH-06 evaluates only the facts required by the applicable policy.

Depending on the Product and rule, relevant facts may include:

  • PH-03 payment amount, currency, Product/use case, current state, Action, or Leg;
  • PH-05 Party status and relationships;
  • PH-05 Payment Instrument type/status and ownership/authority facts;
  • PH-05 validation evidence and freshness;
  • authentication/assurance information;
  • Product configuration;
  • CU-supplied entitlement, account, or eligibility information;
  • prior DragonPay payment activity relevant to configured limits or velocity;
  • prior failures or returns when explicitly required by policy;
  • external fraud/risk results; and
  • other Product-approved facts required by an implemented rule.

PH-06 must not invent missing facts.

When required evidence is missing, stale, unavailable, or failed, the Decision must reflect the applicable policy behavior rather than silently treating the missing evidence as successful.

6. Decision evidence and explainability

A PH-06 Decision must retain enough durable evidence to explain later:

  • which payment and evaluation point were evaluated;
  • which Tenant/Product/use case applied;
  • which published policy version was used;
  • which policy rules materially affected the outcome;
  • the normalized Decision;
  • the controlling and supporting reasons;
  • the relevant non-sensitive measured facts/thresholds when needed for explanation;
  • applicable supporting evidence references;
  • applicable external fraud/risk result references;
  • when the evaluation occurred;
  • when the Decision ceases to be current, if the Decision is time-bound; and
  • which prior Decision it replaces when created through re-evaluation.

Historical Decision evidence is immutable.

PH-06 does not need to duplicate complete PH-03, PH-05, provider, or other source records when stable references and the material evaluated facts are sufficient to explain the Decision.

Sensitive source data is retained only where required and must follow applicable data-protection requirements.

7. Limits and velocity

PH-06 owns shared enforcement of configured payment limits and velocity rules used for policy decisioning.

Supported Product needs may include:

  • maximum amount for one payment;
  • number of payments during a configured period;
  • total payment amount during a configured period;
  • activity by sender/payer;
  • activity by recipient/beneficiary;
  • activity by Payment Instrument;
  • activity between a sender and recipient; and
  • failed/returned activity when explicitly included by policy.

Concurrency invariant

Limit and velocity enforcement must remain correct when multiple payments are evaluated concurrently.

If only one of two simultaneous payments fits within the remaining configured allowance, both must not be approved because they evaluated the same stale prior state.

Technical retry of the same logical payment/evaluation must not consume the same allowance twice.

The exact counter, query, reservation, locking, serialization, or other concurrency implementation is Engineering responsibility.

Velocity-supporting implementation data is not a second payment ledger. PH-03/PH-09 remain authoritative for payment history.

8. External fraud and risk evidence

PH-06 may consume fraud or risk evidence produced by:

  • a Credit Union;
  • payment processor;
  • identity/fraud platform;
  • payment provider; or
  • other approved external source.

PH-06 must preserve:

  • the external source;
  • the external reference/identity when available;
  • the original source outcome;
  • the original score/level when supplied;
  • the normalized DragonPay interpretation needed by policy;
  • the source reason/evidence reference when applicable;
  • the evaluation time and freshness; and
  • the normalization/mapping context needed to understand how the source result was interpreted.

External evidence does not automatically determine the DragonPay Decision unless the applicable policy says it does.

Unavailable, timed-out, or errored external decisioning must not silently become APPROVE.

Changes to normalization logic do not rewrite historical external evidence or prior Decisions.

9. Re-evaluation and current Decision

A payment may require policy evaluation more than once during its lifecycle.

Examples include:

  • initiation;
  • before sender funding;
  • after recipient/destination information becomes available;
  • before payout;
  • before execution;
  • before an explicitly authorized retry; or
  • another Product-defined decision point.

The Product determines when evaluation is required.

A new evaluation may also be required when materially relevant facts change, such as:

  • payment amount/currency;
  • Party or Payment Instrument;
  • ownership/authority evidence;
  • required validation evidence;
  • authentication evidence;
  • policy;
  • external fraud/risk evidence; or
  • expiration of the prior Decision.

Re-evaluation creates a new immutable Decision.

It does not modify the earlier Decision or its supporting evidence.

For workflow use, PH-06 must be able to determine whether a Decision is current for the requested payment scope/evaluation point.

An expired or contextually obsolete Decision must not be returned as though it still authorizes processing.

10. Controlled overrides

DragonPay may allow an authorized operational override when the applicable Product/CU operating model permits it.

An override:

  • references the automated PH-06 Decision;
  • records the effective overridden outcome or constraint;
  • requires an authorized actor;
  • requires a business reason;
  • may be time-bound when applicable;
  • is auditable; and
  • preserves the original automated Decision and evidence unchanged.

Operations and consuming workflows must be able to distinguish:

  • the original automated Decision; from
  • the currently effective overridden outcome.

An override does not erase the original reasons, external risk result, or policy evaluation.

The exact approval workflow, dual-control requirements, user interface, and override persistence mechanics are Product/Engineering decisions only when a supported CU/Product requires them.

11. Route constraints

Policy may produce constraints that affect routing when a supported rule has a genuine route implication.

Examples may include:

  • disallowing a particular route category;
  • restricting the payment to a Product-approved route class; or
  • requiring another policy condition before an otherwise eligible route may be used.

PH-06 provides only the applicable policy constraint.

PH-07 remains responsible for determining actual route eligibility, availability, Connection health, and route selection.

PH-06 does not select the payment route.

12. Durable persistence, idempotency, and write safety

Published policy versions, Decisions, external risk evidence, and overrides are durable records.

Accepted evaluation commands must be idempotent for the same logical evaluation.

Technical retry must not create multiple independent Decisions for the same logical evaluation.

Conflicting reuse of the same logical idempotency identity with materially different evaluation content must be detected rather than silently treated as the original evaluation.

Concurrent policy administration or Decision-supporting writes must not silently overwrite newer authoritative state.

The exact idempotency record, request fingerprint, transaction boundary, uniqueness strategy, and concurrency-control mechanism follow shared DragonPay standards and Engineering design.

13. Product stories

PH06-01 — Configure and Publish Payment Policy

Objective

Maintain the approved policy governing payment decisioning for a Tenant, Product, and applicable use case.

Required behavior

  • Create and modify policy before publication.
  • Configure only DragonPay-supported rules and validated parameters.
  • Prevent arbitrary administrator/Tenant executable rule logic.
  • Validate policy before it can govern payment processing.
  • Publish an immutable policy version.
  • Make one appropriate published version current for new evaluations.
  • Preserve prior versions for Decision explanation and history.
  • Allow policy replacement/retirement without rewriting prior Decisions.

Acceptance

  • Invalid/unsupported rule configuration cannot become active payment policy.
  • A published policy version is not modified in place.
  • New evaluations use the appropriate current policy.
  • Historical Decisions retain the exact policy version they used.
  • Updating current policy does not rewrite an earlier Decision.

PH06-02 — Evaluate Payment Policy

Objective

Produce one explainable Decision for a Product-defined payment evaluation point.

Required behavior

  • Evaluate the payment using the applicable published policy and the authoritative facts required by enabled rules.
  • Do not treat missing, stale, unavailable, or failed required evidence as successful evidence.
  • Produce one normalized Decision and applicable reasons.
  • Retain the rule/evidence information needed to explain the Decision.
  • Preserve applicable route constraints separately from route selection.
  • Handle repeated delivery of the same logical evaluation idempotently.
  • Do not generate a universal DragonPay Risk Score unless a future Product/approved integration explicitly requires one.

Acceptance

  • The same logical evaluation is not duplicated because of technical retry.
  • A Decision identifies the applicable policy version and material reasons.
  • Required missing/stale evidence cannot silently produce approval.
  • A hard eligibility or limit rule may reject a payment without requiring any numeric risk score.
  • PH-04 can use the Decision outcome without interpreting provider-specific risk data.

PH06-03 — Enforce Payment Limits and Velocity

Objective

Apply configured amount and activity limits safely, including concurrent payment activity.

Required behavior

  • Evaluate Product/CU-supported per-transaction and velocity limits.
  • Include only activity defined by the applicable rule.
  • Prevent concurrent evaluations from both consuming allowance that only one payment may use.
  • Prevent technical replay of one logical payment/evaluation from consuming velocity more than once.
  • Preserve enough measured-value/threshold information to explain a resulting Decision.
  • Keep velocity implementation state subordinate to authoritative payment history.

Acceptance

  • A transaction exceeding a configured payment limit is not approved.
  • Two concurrent payments cannot both pass when only one fits within the remaining allowance.
  • Retrying the same logical evaluation does not count the payment twice.
  • Operations can understand which configured limit/velocity condition affected the Decision.

PH06-04 — Consume External Fraud and Risk Results

Objective

Use external fraud/risk evidence in DragonPay policy decisioning without losing the original source result.

Required behavior

  • Record external risk/fraud results supplied for a payment.
  • Preserve the original source outcome and score/level when supplied.
  • Normalize the source result only as needed for DragonPay policy consumption.
  • Retain source identity, timing, freshness, and supporting evidence references as applicable.
  • Apply the external result to a DragonPay Decision only through the applicable policy.
  • Represent unavailable/error external decisioning explicitly rather than defaulting to approval.

Acceptance

  • Authorized operations can distinguish the original provider/CU result from DragonPay's normalized interpretation.
  • A provider score may be retained without requiring DragonPay to generate its own score.
  • Provider timeout/unavailability does not silently become approval when policy requires the external result.
  • Later normalization changes do not rewrite historical external evidence or Decisions.

PH06-05 — Re-evaluate and Preserve Decision History

Objective

Allow Product processing to obtain a new current Decision when relevant facts or evidence change while preserving prior decision history.

Required behavior

  • Allow multiple Product-defined evaluation points during one Payment Request.
  • Determine whether the applicable prior Decision remains current for the requested payment scope and evaluation point.
  • Require re-evaluation when the owning Product or policy requires it because relevant facts/evidence changed or expired.
  • Create a new immutable Decision for each legitimate re-evaluation.
  • Link later Decisions to applicable prior Decisions for historical interpretation.
  • Never modify prior Decisions to make them appear consistent with the newer result.

Acceptance

  • Funding and payout may have separate Decisions under the same Payment Request.
  • An expired Decision is not returned as current authorization.
  • Re-evaluation leaves the prior Decision/evidence intact.
  • A later rejection does not rewrite an earlier approval that legitimately governed an earlier payment step.

PH06-06 — Apply Authorized Decision Overrides

Objective

Allow an authorized operational exception where permitted while preserving the automated policy Decision.

Required behavior

  • Apply an override only to an existing PH-06 Decision.
  • Require appropriate authorization and a business reason.
  • Preserve the original automated Decision and evidence unchanged.
  • Expose automated and effective overridden outcomes separately.
  • Respect override expiration/revocation when applicable.
  • Make override activity auditable.

Acceptance

  • Applying an override does not change the original automated Decision.
  • Unauthorized overrides are rejected.
  • Operations can identify who/why an effective outcome differs from the automated Decision.
  • An expired/revoked override does not continue to authorize payment processing.

14. Engineering-owned / intentionally non-prescribed detail

PH-06 intentionally does not prescribe:

  • a universal DragonPay Risk Score or Risk Level for the initial Product;
  • additive score calculations or score-contribution models;
  • numeric threshold ranges for a future DragonPay scoring model;
  • physical Policy/Decision/RuleResult database tables;
  • a specific rules-engine or rule-handler registry architecture;
  • exact rule-execution sequencing;
  • exact API/operation names;
  • exact policy lifecycle/status implementation;
  • future-effective policy scheduling;
  • exact policy-version numbering;
  • request-fingerprint composition;
  • a PH-06-specific idempotency-record schema;
  • exact Risk Context persistence representation;
  • atomic counter/bucket schema for velocity;
  • locking/serialization/concurrency implementation;
  • detailed external-risk normalization schemas;
  • operations search/sort field catalogs;
  • metrics catalogs;
  • exact override workflow/dual-control implementation;
  • event/outbox implementation; or
  • implementation/build sequence.

Engineering should use established policy, decisioning, idempotency, concurrency, and evidence-preservation patterns appropriate to the supported Product requirements.

Useful technical approaches explored in earlier PH-06 versions may be retained as non-authoritative Engineering reference material where they remain helpful.

15. Scope boundaries

Out of scope

  • Payment Product workflow sequencing.
  • Party or Payment Instrument ownership.
  • Authentication implementation.
  • Payment execution.
  • Route eligibility and route selection.
  • Provider/Connection health.
  • General-purpose customer-authored rules engines.
  • A universal DragonPay fraud-scoring platform for the initial Product.
  • Case-management implementation.
  • Payment lifecycle history implementation.
  • Reporting/analytics platform implementation.
  • Customer balances, settlement accounting, prefunding, reserves, liquidity, or custody of customer funds.

16. PH-06 completion criteria

PH-06 is complete for the initial Product scope when:

  • DragonPay can configure and publish policy for the Tenant/Product/use cases required by the initial Product;
  • policy uses approved rule types/parameters rather than arbitrary executable customer rules;
  • Product-defined evaluation points return durable normalized Decisions and reasons;
  • Decision evidence identifies the applicable policy version and material rule/evidence basis;
  • configured transaction and velocity limits are safe under concurrent payment activity;
  • required missing/stale evidence cannot silently become approval;
  • CU/provider fraud or risk results can be preserved and consumed without requiring DragonPay to generate its own score;
  • re-evaluation produces a new immutable Decision without rewriting prior Decisions;
  • authorized overrides can alter effective workflow outcome without changing the original automated result;
  • PH-04 can determine whether an applicable current Decision permits Product progression;
  • PH-07 can consume applicable policy route constraints without PH-06 selecting a route; and
  • PH-06 provides shared policy/decisioning behavior while allowing Engineering to use proven implementation patterns and introduce numeric scoring later only when Product need justifies it.