RBCPay Security & Transaction Integrity Policy

Security Is a Process, Not a Single Feature

Security is not a single feature.

It is the combination of how participants are verified, how payments are processed and safeguarded, how transactions are authorized, how goods or services are documented, how delivery and acceptance are verified, how disputes are managed, and how every material event is recorded from the first agreement through final completion.

RBCPay operates under one fundamental security principle:

No single person, payment, document, password, verification method, or automated system is relied upon as the sole protection for a transaction.

RBCPay employs multiple independent layers of protection.

The transaction lifecycle follows:

REGISTER → VERIFY → AGREE → FUND → PROTECT → FULFILL → VERIFY PERFORMANCE → ACCEPT → RELEASE → RECORD

Every stage creates evidence that supports the next stage.

1. RBCPay’s Core Security Principles

RBCPay operates according to eight permanent security principles.

1. Identity

RBCPay establishes and maintains reasonable assurance that participants are who they claim to be.

2. Authorization

Sensitive actions are performed only by appropriately authenticated and authorized users.

3. Payment Integrity

Payments are processed only through approved payment channels and according to clearly documented rules.

4. Transaction Integrity

Material transaction terms are recorded before funds are committed.

5. Evidence

Important actions create reliable electronic records.

6. Controlled Release

Where RBCPay’s legally approved payment structure provides conditional settlement, release occurs only when applicable release conditions have been satisfied.

7. Exception Management

Suspicious transactions, disputes and material discrepancies interrupt normal processing and receive appropriate review.

8. Accountability

RBCPay maintains sufficient records to reconstruct significant transaction events.

2. Three Layers of RBCPay Security

RBCPay’s security architecture consists of three primary layers.

Layer One — Participant Security

Who are we dealing with?

RBCPay establishes and maintains appropriate information concerning buyers and sellers.

Layer Two — Payment Security

Where is the money coming from, how is it being processed, and when can it be settled?

Payments move only through approved channels and according to defined authorization and settlement procedures.

Layer Three — Transaction Security

What did the parties actually agree to, and was the agreement performed?

The platform records transaction terms, communications, payment events, fulfillment evidence, acceptance and final disposition.

The three layers operate together.

A verified identity alone does not make a transaction safe.

A successful payment alone does not establish delivery.

A delivery record alone does not establish that the correct product was delivered.

Security comes from connecting these events.

3. ACCOUNT REGISTRATION

Every transaction begins with an identifiable account.

RBCPay requires users to establish an account before accessing material marketplace transaction functions.

At minimum, registration captures appropriate information including:

Legal name;
Email address;
Telephone number;
Country;
Billing or business address where applicable;
Account type;
Buyer or seller status;
Acceptance of Terms of Service;
Acceptance of Privacy Policy; and
Required verification information.

RBCPay assigns each account a unique internal identifier.

That identifier follows the user’s activity throughout the system.

4. BUYER AND SELLER ACCOUNTS

RBCPay distinguishes between:

Buyer Accounts

Used primarily to purchase goods or services.

Seller Accounts

Used to list, sell and receive transaction proceeds.

Buyer + Seller Accounts

Where permitted, one user may operate in both capacities.

Seller accounts are subject to enhanced verification because they may receive transaction proceeds and make representations to buyers.

5. EMAIL AND TELEPHONE VERIFICATION

RBCPay verifies basic contact channels.

Email verification confirms control over the registered email account.

Telephone verification confirms control of the registered telephone number where required.

Changes to these credentials generate security notifications.

A recently changed email address or telephone number may trigger enhanced review before high-risk actions are permitted.

6. IDENTITY VERIFICATION

Transactions are subject to risk-appropriate identity verification.

Depending on the user and transaction, RBCPay may require:

Government-issued identification;
Name verification;
Date-of-birth verification where appropriate;
Address verification;
Telephone verification;
Business registration information;
Corporate registry information;
Authorized representative verification;
Bank-account verification;
Beneficial ownership information where legally required;
Payment-method verification; and
Additional documentation for higher-risk transactions.

Verification is proportionate to transaction risk.

A lower-value transaction does not necessarily require the same controls as a high-value commercial transaction.

7. BUSINESS SELLER VERIFICATION

Businesses selling through RBCPay provide additional information appropriate to their activities.

This may include:

Legal corporate name;
Trade name;
Registered address;
Jurisdiction;
Incorporation or registration number;
Business telephone number;
Business email;
Website;
Authorized representative;
Relevant licensing information;
Bank-account ownership information; and
Additional documentation where risk warrants.

RBCPay distinguishes between:

Verified Business Identity

and

Verified Product or Transaction.

Verification of a company does not automatically verify every item it sells.

8. RISK-BASED VERIFICATION

RBCPay applies increased scrutiny to higher-risk activity.

Factors may include:

Transaction amount;
Product category;
Account age;
Previous transaction history;
Geographic location;
Cross-border activity;
Payment method;
Shipping destination;
Unusual account behaviour;
Recently changed account information;
Transaction velocity;
Previous disputes; and
Other legitimate fraud indicators.

Risk scoring triggers additional review and does not automatically establish wrongdoing.

9. ENHANCED VERIFICATION FOR HIGH-VALUE TRANSACTIONS

RBCPay establishes monetary and risk thresholds requiring enhanced review.

Transaction levels include:

Standard Transactions

Normal account and payment verification.

Elevated-Value Transactions

Additional identity and transaction review.

High-Value Transactions

Enhanced verification and manual review where required.

Exceptional-Value Transactions

Senior compliance, risk or management authorization together with transaction-specific controls.

Thresholds are established according to legal, payment-provider, banking, fraud and operational requirements.

10. MULTI-FACTOR AUTHENTICATION

RBCPay supports or requires multi-factor authentication for sensitive activities.

Enhanced authentication applies particularly to:

Seller accounts;
High-value buyers;
Password changes;
Payment-method changes;
Bank-account changes;
Withdrawal or settlement changes;
Security-setting changes; and
Other high-risk account actions.

Possession of a password alone is not relied upon for the most sensitive account actions.

11. ACCOUNT TAKEOVER PROTECTION

RBCPay monitors for indicators of unauthorized account access.

Potential indicators include:

New devices;
Unusual login locations;
Rapid password changes;
Multiple failed logins;
Changes to payout information;
Changes to telephone or email credentials;
Unusual transaction activity; and
Significant deviations from established account behaviour.

Where appropriate, RBCPay restricts sensitive actions until additional authentication is completed.

12. TRANSACTION CREATION

Once a buyer and seller agree to transact, RBCPay creates a unique transaction record.

Each transaction receives a:

RBCPay Transaction ID

The transaction record contains the material terms of the agreement.

13. REQUIRED TRANSACTION INFORMATION

Depending upon the transaction, RBCPay records:

Buyer;
Seller;
Product or service;
Description;
Quantity;
Condition;
Serial number where appropriate;
Purchase price;
Currency;
Taxes;
Fees;
Shipping costs;
Delivery method;
Delivery address;
Expected delivery date;
Inspection requirements;
Acceptance requirements;
Return conditions;
Payment method;
Release conditions; and
Special terms.

The operating principle is:

Before money moves, RBCPay records what the parties agreed to.

14. TRANSACTION CONFIRMATION

Both parties receive an opportunity to review material terms before funding.

RBCPay displays a transaction summary.

The buyer confirms:

I agree to purchase under these terms.

The seller confirms:

I agree to sell and fulfill under these terms.

Material changes require renewed acknowledgement.

15. TRANSACTION VERSION CONTROL

RBCPay does not permit important transaction terms to be silently changed after agreement.

If:

Price changes;
Quantity changes;
Product changes;
Delivery address changes;
Shipping method changes; or
Material conditions change,

the system creates a revised version.

The transaction record preserves:

Original Terms → Amendment → Acceptance of Amendment

This prevents ambiguity concerning the terms actually accepted.

16. PAYMENT METHODS

RBCPay supports approved payment methods according to its banking, payment-processing and regulatory arrangements.

Approved channels may include:

Visa;
Mastercard;
American Express;
Discover;
ACH;
Bank wire;
Canadian Interac e-Transfer;
Approved cryptocurrency payment channels;
Zelle where appropriately supported;
Cheque;
Money order;
Cash under specifically controlled procedures; and
Other approved methods.

Each payment method is governed by its own operating procedure.

17. PAYMENT VERIFICATION

A payment instruction is not treated as confirmed funds.

RBCPay distinguishes between statuses including:

Payment Initiated

Payment Pending

Payment Confirmed

Payment Under Review

Payment Failed

Payment Reversed

Transaction Eligible for Settlement

The applicable status is visible to relevant users.

18. FUNDS SECURITY

The handling of transaction funds matches RBCPay’s actual legal, banking and payment-processing architecture.

Where customer funds are received, held, safeguarded or conditionally released by a regulated third-party payment provider, RBCPay accurately identifies that provider and its role.

RBCPay does not describe money as being held in a particular legal arrangement unless that description is factually and legally correct.

The operating principle is:

Funds are not treated as freely available to the seller merely because the buyer initiated payment.

Settlement follows applicable payment rules, risk controls and transaction conditions.

19. SEPARATION OF PLATFORM OPERATING FUNDS

Where legally applicable to the payment structure used by RBCPay, customer transaction funds are appropriately separated from RBCPay’s ordinary operating finances.

Customer transaction funds are not used for:

Payroll;
Rent;
Advertising;
Corporate expenses;
Lending;
Investments;
Working capital; or
Unrelated transactions.

The safeguarding structure follows RBCPay’s banking, payment-provider and legal requirements.

20. PAYMENT RECONCILIATION

Every payment is matched to:

Payment → Transaction ID → Buyer → Seller → Amount → Payment Method → Status

Unmatched payments enter an exception workflow.

They are not manually assigned based solely on an email or telephone request.

21. NO PAYMENT INSTRUCTION CHANGES BY EMAIL ALONE

Payment-redirection fraud presents a major risk in high-value transactions.

RBCPay applies the following rule:

Banking or settlement instructions are never changed solely on the basis of an email, text message or telephone request.

Changes require authenticated account access and additional verification.

High-value changes receive manual review.

22. PRODUCT DOCUMENTATION

For physical goods, sellers provide sufficient information to identify the product.

Depending upon the product, this may include:

Photographs;
Model;
Manufacturer;
Serial number;
VIN;
Specifications;
Condition;
Quantity;
Ownership records;
Purchase invoice;
Warranty information;
Certification; and
Inspection reports.

23. HIGH-VALUE PRODUCT VERIFICATION

High-value products receive enhanced verification where required.

RBCPay may require:

Additional photographs;
Date-specific photographs;
Serial-number photographs;
Live video inspection;
Independent inspection;
Warehouse confirmation;
Ownership documents;
Manufacturer documentation; or
Other evidence appropriate to the asset.

Verification is documented in the transaction record.

24. SELLER FULFILLMENT

Once applicable payment conditions have been satisfied, the seller proceeds with fulfillment.

The seller provides:

Shipping carrier;
Tracking number;
Shipment date;
Shipping documents;
Bill of lading where applicable;
Serial numbers where relevant;
Insurance information where applicable; and
Other required fulfillment evidence.

The transaction then moves to:

FULFILLMENT IN PROGRESS

25. DELIVERY MONITORING

RBCPay records relevant shipping events where technically available.

Possible statuses include:

Shipment Created

Carrier Received

In Transit

Out for Delivery

Delivered

Delivery Exception

Returned

Tracking information is linked to the transaction record.

26. PROOF OF DELIVERY

For higher-value transactions, simple tracking may not be sufficient.

RBCPay may require:

Signature confirmation;
Named recipient;
Commercial bill of lading;
Delivery receipt;
Photographic evidence;
Warehouse receipt;
Freight documentation; or
Independent confirmation.

Evidence requirements increase with transaction value and risk.

27. BUYER INSPECTION

Where the transaction provides an inspection period, the buyer receives a defined opportunity to inspect the goods.

The inspection period is clearly stated.

For example:

Inspection period begins upon verified delivery.

During the inspection period, the buyer may:

ACCEPT

The transaction proceeds toward completion.

REPORT A PROBLEM

The transaction enters dispute review.

REQUEST ADDITIONAL REVIEW

Where permitted under the transaction terms.

Silence constitutes acceptance only where the Terms expressly provide for that result and applicable law permits it.

28. ACCEPTANCE

Acceptance is a significant transaction event.

RBCPay records:

User;
Transaction ID;
Date;
Time;
Acceptance action;
Relevant device or session information where appropriate; and
Transaction version accepted.

Once valid acceptance occurs, the transaction becomes eligible for settlement subject to payment-provider rules and applicable holds.

29. RELEASE AUTHORIZATION

Where RBCPay’s legally approved payment structure uses conditional settlement, no single ordinary employee has unilateral authority to arbitrarily release a high-value payment.

Release depends upon objective system conditions.

For example:

Payment Confirmed + Seller Fulfilled + Delivery Verified + Inspection Completed/Acceptance + No Active Dispute = Eligible for Release

Exceptional-value transactions require additional approval where designated by policy.

30. DUAL CONTROL

RBCPay uses dual control for designated sensitive manual actions.

Dual control means:

One authorized person initiates.

A second authorized person reviews or approves.

Dual control applies to designated activities including:

High-value manual releases;
Exceptional refunds;
Banking-information changes;
Account overrides;
Security overrides; and
Other high-risk administrative actions.

This reduces internal fraud and human error.

31. DISPUTE FREEZE

A timely and eligible dispute interrupts normal transaction completion where transaction rules, payment-provider rules and applicable law permit.

The transaction status changes to:

TRANSACTION UNDER REVIEW

Relevant funds are not released solely because one party demands immediate payment.

32. DISPUTE EVIDENCE

RBCPay collects relevant evidence from both parties.

Evidence may include:

Listing;
Product photographs;
Transaction terms;
Communications;
Invoice;
Payment record;
Tracking;
Bill of lading;
Delivery confirmation;
Inspection report;
Serial numbers;
Videos;
Acceptance records; and
Other relevant documentation.

33. FAIR DISPUTE REVIEW

RBCPay does not automatically favour buyers or sellers.

Review is evidence based.

Each party receives an opportunity to explain its position where appropriate.

The review addresses:

What was agreed?
What was paid?
What was shipped or performed?
What was received?
What does the evidence demonstrate?
What do the applicable transaction rules require?

34. POSSIBLE DISPUTE OUTCOMES

Subject to RBCPay’s legal authority and payment-provider rules, outcomes may include:

Transaction completion;
Full refund;
Partial refund;
Return of goods;
Replacement;
Additional inspection;
Payment release;
Continued review; or
Referral to an external provider or appropriate authority.

RBCPay does not promise a remedy it lacks the legal or operational authority to provide.

35. TRANSACTION AUDIT TRAIL

Every significant event is logged.

The audit trail may record:

Account creation;
Verification;
Login;
Transaction creation;
Terms;
Amendments;
Acceptance;
Payment initiation;
Payment confirmation;
Shipment;
Delivery;
Buyer acceptance;
Dispute;
Administrative review;
Refund;
Settlement;
Account changes; and
Security events.

36. RECORD IMMUTABILITY

Historical transaction records are preserved when information is edited.

Where practical:

RBCPay does not overwrite history — RBCPay creates a new version.

For example:

Original delivery address
↓
Address-change request
↓
Verification
↓
New delivery address

The system retains the complete history.

37. TIMESTAMPS

Important actions contain reliable timestamps.

Records identify:

WHAT happened

WHO initiated it

WHEN it happened

WHICH transaction was affected

WHAT changed

This creates accountability and traceability.

38. ADMINISTRATOR SECURITY

RBCPay’s employees and administrators receive only the privileges required for their responsibilities.

Administrative accounts require:

Individual credentials;
Multi-factor authentication;
Role-based permissions;
Access logging;
Session controls;
Periodic access reviews; and
Immediate access termination when employment or authorization ends.

Shared administrator passwords are prohibited.

39. ROLE-BASED ACCESS CONTROL

Employees access only information necessary for their roles.

For example:

Customer Support

Transaction and customer-service information.

Risk Team

Verification and fraud information.

Finance

Payment and reconciliation information.

Security

Security events and relevant technical records.

System Administrators

Technical infrastructure according to operational necessity.

Unrestricted access is not granted merely for convenience.

40. ENCRYPTION

Sensitive information is protected using modern encryption practices appropriate to the information and system.

This includes:

Data in Transit

Information transmitted between users and RBCPay uses secure encrypted connections.

Sensitive Data at Rest

Sensitive stored information receives appropriate protection.

Passwords

Passwords are not stored in readable plaintext.

41. PAYMENT CARD SECURITY

RBCPay minimizes direct exposure to payment-card information.

Where possible, card information is handled through qualified payment-processing infrastructure.

RBCPay does not unnecessarily store:

Full card numbers;
CVV/CVC security codes; or
Other sensitive authentication information.

Applicable PCI DSS requirements are identified and followed.

42. PERSONAL INFORMATION

RBCPay collects only personal information reasonably necessary for legitimate business, security, transaction and legal purposes.

Sensitive information is not collected merely because it might later be useful.

RBCPay maintains:

Privacy Policy;
Retention schedule;
Access controls;
Data deletion procedures;
Incident response;
Vendor requirements; and
Privacy complaint procedures.

43. DOCUMENT SECURITY

Identity documents receive heightened protection.

Access is restricted to authorized personnel and systems.

Where practical, RBCPay may use specialized identity-verification providers to reduce unnecessary internal retention of highly sensitive identity information.

44. FRAUD MONITORING

RBCPay monitors transactions for indicators of potential fraud.

Possible indicators include:

Unusually high transaction value;
New seller with immediate high-value listing;
Repeated failed payment attempts;
Multiple accounts using related information;
Rapid changes to banking details;
Buyer and seller using suspiciously related credentials;
Geographic anomalies;
Unusual login behaviour;
Multiple complaints;
Suspicious shipping changes; and
Attempts to bypass RBCPay.

Flags trigger review and are not treated as automatic proof of wrongdoing.

45. OFF-PLATFORM TRANSACTION PROTECTION

RBCPay strongly discourages users from moving transactions outside the platform.

Users are advised:

RBCPay cannot provide the same transaction records, monitoring or platform procedures for payments and agreements completed outside RBCPay.

Messages requesting off-platform payment may be treated as a risk indicator.

46. SOCIAL ENGINEERING PROTECTION

RBCPay communicates the following security requirements:

RBCPay never requests a user’s password.

Users never provide one-time authentication codes to another person.

Unexpected payment instructions are verified through the authenticated RBCPay account.

Funds are not sent solely on the basis of an unsolicited email or text message.

47. SECURITY NOTIFICATIONS

Users receive notifications for designated significant account events, including:

Password change;
Email change;
Telephone change;
New payment method;
Bank-account change;
New login where appropriate;
Transaction funding;
Shipment;
Delivery;
Dispute;
Refund;
Settlement; and
Account restriction.

This allows users to identify unauthorized activity promptly.

48. HIGH-VALUE TRANSACTION PROTOCOL

RBCPay maintains a separate protocol for significant transactions.

A high-value transaction may require:

LEVEL 1 — Identity Verification

Buyer and seller.

LEVEL 2 — Business Verification

Where applicable.

LEVEL 3 — Payment Verification

Confirmation through approved payment channels.

LEVEL 4 — Asset Verification

Serial number, ownership evidence, inspection or equivalent documentation.

LEVEL 5 — Fulfillment Verification

Shipping and delivery evidence.

LEVEL 6 — Acceptance

Buyer inspection or acceptance where applicable.

LEVEL 7 — Release Authorization

System eligibility plus additional approval where required.

49. EXCEPTIONAL TRANSACTION COMMITTEE

Extremely high-value or unusual transactions may require approval from designated senior personnel.

The review may involve:

Risk;
Compliance;
Finance; and
Management.

No salesperson or individual employee has unilateral authority to bypass established security procedures for the purpose of completing a transaction.

50. CASH TRANSACTIONS

Cash presents unique security and compliance risks.

Where RBCPay permits cash, a separate policy governs:

Maximum amounts;
Accepted locations;
Identification;
Receipts;
Counting;
Dual verification;
Deposit;
Source-of-funds considerations;
Recordkeeping; and
Applicable reporting obligations.

Large anonymous cash transactions are not treated as ordinary marketplace payments.

51. CHEQUES AND MONEY ORDERS

A cheque appearing valid does not establish final payment.

RBCPay distinguishes:

Received

from

Cleared/Confirmed

Goods or settlement are not released solely because a cheque has been physically received.

Fraudulent bank drafts, certified cheques and money orders remain recognized transaction risks.

52. CRYPTOCURRENCY

Cryptocurrency transactions operate under a separate policy.

RBCPay establishes:

Approved digital assets;
Approved provider;
Wallet procedures;
Required blockchain confirmations;
Exchange-rate methodology;
Network-fee responsibility;
Refund methodology;
Incorrect-address policy;
Fraud procedures;
Sanctions procedures; and
Applicable AML and compliance requirements.

Cryptocurrency is not implemented or treated as an ordinary payment method without appropriate controls.

53. COMPLIANCE PROGRAM

RBCPay designates responsibility for compliance.

The program covers, as applicable:

Consumer protection;
Privacy;
Payments regulation;
Anti-money-laundering requirements;
Sanctions;
Payment-card requirements;
Tax;
Record retention;
Complaints;
Cybersecurity; and
Marketplace rules.

54. SECURITY INCIDENT RESPONSE

RBCPay maintains a written Security Incident Response Plan.

The plan addresses:

IDENTIFY

Determine what happened.

CONTAIN

Stop continuing exposure.

PRESERVE

Protect logs and evidence.

INVESTIGATE

Determine scope and cause.

NOTIFY

Determine legally required user, regulator, insurer, payment-provider or law-enforcement notifications.

REMEDIATE

Correct the vulnerability.

REVIEW

Determine how recurrence is prevented.

55. BUSINESS CONTINUITY

Security includes continuity of critical services.

RBCPay maintains:

Backups;
Disaster recovery;
Infrastructure redundancy where appropriate;
Recovery procedures;
Payment reconciliation procedures;
Emergency contacts;
Vendor escalation procedures; and
Business continuity planning.

56. SECURITY TESTING

RBCPay conducts periodic security testing appropriate to the platform’s risk profile.

Testing may include:

Vulnerability scanning;
Software dependency review;
Access review;
Security configuration review;
Penetration testing;
Backup restoration testing;
Incident-response exercises; and
Vendor security reviews.

Security controls are validated through testing rather than assumed to operate correctly.

57. VENDOR MANAGEMENT

RBCPay evaluates critical providers supporting marketplace operations.

Assessment may include:

Security;
Privacy;
Reliability;
Regulatory status where applicable;
Data handling;
Incident procedures;
Business continuity; and
Contractual responsibilities.

Critical vendors receive periodic reassessment.

58. COMPLAINT MANAGEMENT

RBCPay treats complaints as potential risk intelligence.

Repeated complaints concerning the same:

Seller;
Buyer;
Product;
Payment account;
Address;
Device;
Shipping destination; or
Behaviour

may indicate a broader problem.

RBCPay maintains centralized complaint records.

59. ACCOUNT RESTRICTION

RBCPay retains contractual authority to restrict accounts where necessary to protect the marketplace, users or legal and compliance obligations.

Reasons may include:

Suspected fraud;
Account compromise;
False information;
Prohibited activity;
Payment risk;
Legal requirements;
Repeated violations; or
Serious security concerns.

Restrictions are documented.

60. TRANSACTION SECURITY STATUS

RBCPay provides users with a clear transaction timeline.

For example:

✓ Buyer Verified

✓ Seller Verified

✓ Terms Accepted

✓ Payment Confirmed

✓ Seller Fulfilled

✓ Shipment Verified

✓ Delivered

✓ Buyer Accepted

✓ Transaction Completed

Where attention is required:

⚠ REVIEW REQUIRED

⚠ TRANSACTION UNDER REVIEW

This provides transparency without exposing confidential fraud-detection information.

61. THE RBCPAY SECURITY CHAIN

Every completed transaction produces a logical security chain:

WHO?

Verified buyer and seller information.

↓

WHAT?

Documented product or service and transaction terms.

↓

HOW MUCH?

Recorded price, currency, taxes and fees.

↓

HOW WAS IT PAID?

Documented approved payment channel.

↓

WAS PAYMENT CONFIRMED?

Payment status recorded.

↓

WAS THE ORDER FULFILLED?

Seller fulfillment evidence.

↓

WAS IT DELIVERED?

Delivery documentation.

↓

WAS IT ACCEPTED?

Buyer acceptance or applicable completion event.

↓

WAS SETTLEMENT AUTHORIZED?

Release criteria satisfied.

↓

WHAT IS THE FINAL RECORD?

Complete transaction history retained according to RBCPay’s retention policy.

62. RBCPAY INTERNAL SECURITY RULE

RBCPay adopts the following as a formal internal requirement:

No transaction advances to the next material stage merely because one party requests it. Advancement requires the authentication, payment status, transaction records and objective conditions established for that transaction type.

This requirement applies to buyers, sellers, employees and administrators.

63. SECURITY GOVERNANCE

Security has defined ownership within RBCPay.

RBCPay assigns responsibility for:

Information Security

Protecting systems and accounts.

Risk and Fraud

Monitoring suspicious activity.

Compliance

Managing applicable regulatory requirements.

Privacy

Managing personal-information governance.

Finance

Managing payment reconciliation.

Customer Operations

Providing transaction support.

Management

Providing oversight and accountability.

Where one individual performs multiple roles, each responsibility remains separately defined and documented.

64. MANAGEMENT REPORTING

Management periodically reviews:

Transaction volume;
Transaction value;
Failed payments;
Refunds;
Disputes;
Chargebacks;
Fraud losses;
Account restrictions;
Security incidents;
Complaints;
High-value transactions;
Manual overrides; and
Unusual transaction activity.

Security performance is measurable and subject to management oversight.

65. NO UNDOCUMENTED OVERRIDES

RBCPay applies the following rule:

There are no undocumented security overrides.

If an authorized manager overrides a control, the system or operating record identifies:

Who authorized it;
What was overridden;
Why;
Date and time;
Supporting evidence; and
Any secondary approval.

66. ANNUAL SECURITY REVIEW

RBCPay reviews this policy at least annually and following significant incidents, major technology changes, material payment changes or significant regulatory developments.

The review considers:

New fraud patterns;
Regulatory changes;
New payment methods;
New product categories;
Cybersecurity developments;
Complaint trends;
Payment losses;
Vendor changes; and
Operational weaknesses.

Policies and procedures are updated where necessary.

67. RBCPAY PUBLIC SECURITY COMMITMENT

RBCPay’s public security commitment is:

RBCPay is designed around layered transaction security. We combine participant verification, authenticated accounts, documented transaction terms, approved payment processes, fulfillment records, delivery evidence, fraud monitoring and structured dispute procedures to create a more transparent and accountable environment for buyers and sellers.

Every material stage of an eligible transaction creates a record. From initial agreement through payment, fulfillment, delivery, acceptance and completion, our processes are designed to reduce risk and provide both parties with greater visibility into the transaction.

No marketplace can eliminate every risk. RBCPay identifies, reduces and manages those risks through structured controls rather than relying upon trust alone.

68. RBCPAY SECURITY STANDARD

RBCPay summarizes its security architecture in five principles:

VERIFY. DOCUMENT. PROTECT. CONFIRM. RECORD.

VERIFY

Know the participants.

DOCUMENT

Record exactly what they agreed to.

PROTECT

Apply appropriate account, payment, privacy and fraud controls.

CONFIRM

Require evidence before critical transaction milestones.

RECORD

Maintain an auditable history of what occurred.

69. FINAL OPERATING PRINCIPLE

RBCPay does not build security around the assumption that every transaction will proceed without difficulty.

RBCPay builds security around the possibility that something may go wrong.

For every transaction, RBCPay maintains systems and procedures capable of addressing:

Can we establish who participated?

Can we establish what was agreed?

Can we establish what was paid?

Can we establish what was shipped or performed?

Can we establish what was delivered?

Can we establish what the buyer accepted?

Can we establish why funds were released or refunded?

Can we reconstruct the transaction afterward?

RBCPay’s transaction-security framework is founded on:

Identity + Payment Integrity + Transaction Evidence + Controlled Authorization + Accountability

Security is not merely a feature displayed on the RBCPay website.

It is the operating structure governing every transaction from registration through final completion.

70. REQUIRED RBCPAY SUPPORTING POLICIES

This Security & Transaction Integrity Policy is supported by the following operational policies and procedures:

Terms of Service
Buyer Protection Policy
Seller Protection Policy
Payment & Settlement Policy
Transaction Release Policy
Identity Verification / KYC Policy
High-Value Transaction Policy
Fraud Prevention & Risk Policy
Dispute Resolution Policy
Refund & Cancellation Policy
Privacy Policy
Information Security Policy
Data Retention & Destruction Policy
Incident Response Plan
Business Continuity & Disaster Recovery Plan
Administrator Access Policy
Payment Instruction Change Policy
Cryptocurrency Policy, where offered
Cash / Cheque / Money Order Policy, where offered
Vendor & Payment Provider Management Policy
Complaint Handling Policy
High-Value Manual Approval Procedure
Security Override & Exception Policy
Annual Compliance and Security Review

All supporting policies remain consistent with this policy, RBCPay’s actual technology, its payment architecture, its contractual obligations and applicable legal requirements.

71. POLICY COMPLIANCE

All RBCPay employees, contractors, administrators and authorized representatives with responsibilities involving marketplace transactions, customer information, payment activity, account administration, risk review or transaction settlement are required to comply with this policy.

Failure to follow an applicable security control, approval procedure, documentation requirement or access restriction may result in:

Removal of system access;
Transaction review;
Internal investigation;
Corrective action;
Contractual action;
Employment action where applicable; or
Referral to appropriate legal, regulatory or law-enforcement authorities where warranted.

No employee, contractor or representative may bypass this policy for convenience, commercial pressure, transaction urgency or customer preference.

72. POLICY EXCEPTIONS

Exceptions to this policy require documented authorization.

An exception record identifies:

The applicable policy requirement;
The reason for the exception;
The transaction or system affected;
The risk created by the exception;
Compensating controls;
Approving authority;
Effective date;
Expiration date where applicable; and
Supporting documentation.

Temporary exceptions do not become permanent operating practices without formal policy review and approval.

73. POLICY RECORDKEEPING

RBCPay maintains records required to demonstrate implementation of this policy.

Records may include:

Verification records;
Security logs;
Access records;
Payment records;
Transaction records;
Dispute files;
Approval records;
Exception records;
Incident reports;
Vendor assessments;
Training records;
Security-test results;
Management reviews; and
Policy-review records.

Records are retained according to RBCPay’s applicable data-retention requirements.

74. STAFF TRAINING

Personnel with responsibilities under this policy receive training appropriate to their role.

Training includes, where applicable:

Account security;
Authentication requirements;
Fraud indicators;
Social engineering;
Payment-redirection fraud;
Customer verification;
High-value transactions;
Privacy;
Handling of sensitive information;
Dispute procedures;
Payment status interpretation;
Security escalation;
Administrative access;
Incident reporting; and
Policy exceptions.

Training is updated when material procedures or risks change.

75. SEGREGATION OF DUTIES

RBCPay separates incompatible duties where transaction value, risk or system privileges justify doing so.

No single individual is given unnecessary end-to-end control over:

Transaction approval;
Payment confirmation;
Settlement authorization;
Refund authorization;
Banking-information changes;
Administrator access; and
Audit-log modification.

Where staffing limitations require overlapping responsibilities, compensating controls and secondary review are documented.

76. CHANGE MANAGEMENT

Material changes to RBCPay’s security, payment or transaction infrastructure follow a controlled change-management process.

Changes may include:

New payment providers;
New payment methods;
New authentication systems;
New marketplace functionality;
New settlement workflows;
New user verification providers;
New high-value product categories;
New data-storage systems; and
Material changes to transaction release logic.

Changes are reviewed for:

Security impact;
Privacy impact;
Payment risk;
Fraud risk;
Compliance implications;
User impact; and
Business continuity.

Material controls are tested before production deployment where appropriate.

77. PAYMENT PROVIDER DEPENDENCIES

Where RBCPay relies upon a third-party payment processor, bank or payment service provider, RBCPay follows the provider’s applicable rules and recognizes that transaction availability, reversals, holds, settlement timing and payment finality may depend upon that provider.

RBCPay does not represent a payment as irreversible, finally settled or unconditionally available before applicable provider requirements have been satisfied.

78. TRANSACTION FINALITY

A transaction is treated as completed only after all applicable completion requirements have been satisfied.

Depending upon the transaction, this may include:

Payment confirmation;
Applicable fraud review;
Seller fulfillment;
Verified delivery;
Buyer acceptance;
Expiration of an applicable inspection period;
Resolution of active disputes;
Applicable payment-provider conditions; and
Final settlement authorization.

A transaction status displayed as complete reflects the status within RBCPay’s system and remains subject to rights, reversals or obligations imposed by applicable law or third-party payment networks.

79. SECURITY BY DESIGN

RBCPay incorporates security controls into product and workflow design.

New functionality is evaluated by asking:

What information is collected?
Who can access it?
What transaction risk does the feature create?
Can the feature move money?
Can it change settlement instructions?
Can it alter transaction evidence?
Can it expose sensitive information?
Can it be abused by a compromised account?
What logging is required?
What approval is required?
How is suspicious use detected?

Security requirements form part of the feature design rather than being added only after launch.

80. POLICY STATEMENT

RBCPay adopts this Security & Transaction Integrity Policy as a core operational requirement of the platform.

RBCPay’s security model is based on layered controls, documented transactions, verified participant information, controlled payment processes, evidence-based fulfillment, protected account access, structured dispute handling and auditable decision-making.

Every RBCPay transaction is governed by the principle that:

Trust is supported by verification. Payment is supported by confirmation. Delivery is supported by evidence. Release is supported by authorization. Every material action is supported by a record.

This policy remains in effect until amended, replaced or formally withdrawn by RBCPay.

Important Legal and Operational Notice

This policy establishes RBCPay’s internal security and transaction-integrity requirements.

Implementation of particular provisions remains subject to the payment processors, banks, technology providers, transaction methods, contractual arrangements and regulatory requirements applicable to RBCPay’s actual operations.

Descriptions concerning the holding, safeguarding, protection, insurance, guarantee, trust status, segregation or conditional release of customer funds are used only where RBCPay’s actual legal and financial arrangements support those descriptions.

RBCPay maintains consistency between its public representations, contractual terms, technical systems, payment flows and operational practices.