Remote Deposit Capture and Mobile Check Deposit. Implement mobile and commercial RDC across capture, uncertain submissions, limits, cross-channel duplicates, restrictive endorsements, original retention and settlement reconciliation.
A contractor photographs a $3,650 customer check from the passenger seat of a parked van. The app shows a spinning indicator, then closes. The contractor still has the paper and cannot tell whether the bank received the deposit. At the office, a colleague offers to take the check to a branch. That apparently helpful action can create a second presentment if the mobile submission already succeeded.
Chapter 39 follows remote deposit capture from enrollment through image submission, bank acceptance, collection and servicing. Chapters 36–38 established the check lifecycle, image exchange, availability and returns. This chapter focuses on what changes when capture occurs away from the bank and the customer or its service provider retains the original. Lockbox processing and conversion to ACH follow in Chapter 40.
A photograph is a submission of payment evidence. The bank must establish acceptance, preserve one item identity and control the original paper before the customer treats the deposit as complete.
For a roughly 60-minute core session, spend about 35 minutes on Section 1, Sections 4–8 and Section 11. For the next 10 minutes, use the chapter’s three diagrams to follow remote submission, bank acceptance and original-paper controls. Use 10 minutes to work through one case in Section 15, then spend the final 5 minutes explaining: How should the bank handle a mobile-deposit timeout while preventing a second presentment? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Customers, values and incidents are fictional. Limits, status names, retention examples and internal architecture are illustrative unless linked to a specific requirement. The bank's approved RDC agreement and applicable law determine its actual customer obligations and product treatment.
Chapter navigator
- RDC as a bank deposit channel
- Product eligibility and customer enrollment
- Entitlements devices and secure access
- Capturing the front back and item data
- Submission acceptance and customer status
- Limits exposure and availability promises
- Duplicate detection across channels and banks
- RDC indemnity and restrictive endorsements
- Original-paper retention storage and destruction
- Review rejection and post-acceptance exceptions
- Collection settlement and customer posting
- RDC fraud monitoring and financial-crime controls
- Reconciliation reporting and customer support
- Vendor resilience and production readiness
- Worked cases and channel testing
- Role checklist and learning closure
1. RDC as a bank deposit channel
Remote deposit capture, or RDC, allows a customer or another authorized capture location to transmit images and associated information for deposit processing. Mobile check deposit is one form of RDC. A business using a desktop scanner is another. The channel can reduce physical trips and accelerate receipt of information, but it does not make the check an instant payment or remove the paying bank's role.
The bank still needs a deposit relationship, accepted instrument, collection route, customer posting and financial reconciliation. The distinctive feature is the location and control of capture. The bank may not inspect the original paper before accepting the image, and the original may remain outside its custody. That changes the evidence available at acceptance and creates duplicate-deposit and document-retention concerns.
A mobile app, scanner vendor or fintech interface is not automatically the depositary bank. The product should identify the bank that holds the deposit account and accepts the deposit under the arrangement. The customer-facing interface can simplify the experience, but the underlying responsibility map must remain clear to operations, legal and the customer when something goes wrong.
RDC should also be distinguished from entering routing and account information to initiate an ACH debit. A scanned check continuing through image collection remains a check transaction. Conversion into an ACH entry requires its own eligibility, authority and processing treatment. The word electronic does not make those processes interchangeable.
The channel promise begins before the photograph
The contractor should know which checks the product accepts, which account will receive the deposit, what the stated limit means, how the bank communicates acceptance and what to do with the paper. These points should be available at the moment of use, not hidden in a long agreement that the customer cannot recall while the app is waiting for a response.
The bank should define whether a displayed success means upload received, deposit accepted, review completed or another stage. A friendly confirmation can still be precise. For example, a product may acknowledge receipt and state that the deposit is under review, then provide a separate acceptance message. What matters is that the bank's actual workflow matches the words shown.
The same care applies to availability. A product that displays an expected date should explain any review or exception conditions that genuinely apply. It should not display a definitive release promise while retaining an undisclosed ability to change it arbitrarily. Chapter 38 explains the wider availability framework; the RDC channel must implement its own lawful and clearly disclosed treatment.
The bank should consider how customers recover from uncertainty. A person with the original paper in hand can easily try another bank or a branch. The app should give a stable submission reference and a way to check the original outcome. A vague error page that says try again encourages duplicate risk even if the backend has sophisticated detection.
A well-designed RDC service therefore joins convenience to a controlled deposit lifecycle. The customer can complete a remote action without understanding interbank file formats, while the bank retains enough evidence to determine what was received, accepted, collected and credited.
2. Product eligibility and customer enrollment
Enrollment should establish who can use RDC, for which accounts and under which conditions. A consumer mobile product and a commercial scanner service can have different risk profiles, limits and operating responsibilities. The bank should assess the actual customer, expected activity and supported instruments rather than copy one set of conditions across every remote channel.
For a business, relevant facts can include its business model, expected check volume and value, types of payers, locations of capture, staff access and document controls. The bank should understand whether the business deposits its own receivables or processes payments for others. The latter can create different legal, fraud and financial-crime considerations and should not be accepted merely because the scanner produces valid images.
For a consumer, the bank needs appropriate account eligibility and authentication, with limits and review based on its approved product and risk approach. A long account relationship may support one treatment, while a newly opened account may require another. These are bank decisions subject to applicable law; the chapter does not prescribe universal mobile-deposit limits or waiting periods.
The FFIEC's electronic-banking guidance discusses RDC customer suitability, expected activity, monitoring, contracts, training and record security. Its focus is managing the risks of remote capture, not treating a successful scan as sufficient due diligence. The bank should use the current guidance and its own risk assessment to design the service. FFIEC electronic banking and RDC.
The business model can change after onboarding
A small property manager may initially deposit rent checks from a few tenants. Later it begins collecting for several unrelated owners and opens a shared processing office. The original volume and entitlement assumptions may no longer fit. The bank should have a process to identify and assess material changes rather than rely indefinitely on the first enrollment form.
Expected activity should be useful enough to compare with actual use. “Deposits checks” is too broad to explain whether a sudden increase is plausible. The bank can record anticipated monthly value, typical item size, payer types and capture locations at an appropriate level. These are risk-assessment inputs, not public transaction limits. Significant deviations should prompt inquiry and review, not an automatic accusation.
The enrollment agreement should identify the customer's responsibilities for authorized users, accurate data, eligible items, duplicate prevention, original retention, secure disposal and cooperation with investigations. It should also explain the bank's supported suspension or termination rights and the handling of outstanding items. Ending access to RDC does not erase prior deposits or claims.
Commercial onboarding should include operational demonstration where appropriate. The bank can ask the customer to show how checks are received, scanned, balanced, marked, stored and destroyed. A business may have strong financial statements but weak document handling. A scanner sitting on a shared reception desk with no controlled storage creates a different risk from a well-managed processing area.
The bank should make responsibilities practical. A customer told only to avoid duplicates may not know how to handle a jammed batch or an uncertain submission. Training should use the actual product screens and escalation path. Enrollment is successful when the customer can operate the service safely during an ordinary error, not just complete a perfect first deposit.
3. Entitlements devices and secure access
RDC access should be limited to authorized users and eligible accounts. Commercial services may distinguish the ability to create a deposit, review or approve it, submit it and view history. Consumer mobile services should bind the submission to the authenticated customer and selected account. The bank should not rely on possession of a scanner or app installation as evidence of deposit authority.
Device and session controls should reflect the risk of account takeover and unauthorized use. A trusted device can support risk assessment, but it does not establish the legitimacy of every submitted check. Conversely, a new device can be legitimate. The bank should use its supported authentication and review process rather than treat device identity as a complete substitute for customer and transaction controls.
A commercial scanner can be connected to a workstation used for other business tasks. The bank and customer should understand the security responsibilities for that environment, including access, software updates, local storage and support. A vendor's control over its application does not automatically secure the customer's whole network or prevent an employee from rescanning the paper elsewhere.
Remote support also needs boundaries. A technician diagnosing a scanner issue should not receive unrestricted access to customer account credentials or full check archives. The bank should define approved diagnostic data and support methods. Logs should help establish the failure without unnecessarily exposing account numbers, signatures or images.
Separating preparation from release in a business office
Consider a wholesaler where a clerk scans incoming checks and a supervisor releases the deposit. The system should bind approval to the specific item population and total reviewed. If the clerk changes an amount or adds an item after approval, the original approval should not silently authorize the new version. The product should require the appropriate renewed review under its design.
A shared login defeats that control because the bank cannot identify who prepared or approved the deposit. The customer agreement and training should make user administration clear. When an employee leaves, the business should remove access through the supported process. The bank should also be able to suspend a compromised user or device without losing the history of deposits already submitted.
Entitlements should include account selection. A business with several entities may use one office to process checks for each. The scanner application should prevent an authorized user for one account from accidentally depositing another entity's receipts into it. Payee and account review, clear account labels and controlled batch assignment can reduce this risk. The exact design depends on the bank's accepted service model.
The bank should test what happens when a session expires during submission. The front end may require reauthentication while the backend has already accepted the deposit. Returning the customer to a blank form without a status lookup can encourage a duplicate. Authentication recovery and payment-state recovery should be coordinated but remain distinct functions.
Security reporting should identify unusual access and submission patterns in context. A burst of deposits after a credential reset may need review, but the bank should preserve the legitimate customer's ability to obtain a clear status and support. The objective is secure, explainable access to the deposit service, not a collection of controls that leave both customers and staff uncertain about what happened.
Shared devices and changes in responsibility
A commercial customer may use a scanner connected to a workstation shared by several employees. The bank should distinguish device identity from user authority. A registered device does not establish that every person using it may deposit into every account. Session controls and customer entitlements should identify who captured, approved and submitted each deposit, with separation where the service requires it.
An employee leaving the customer presents a practical test. Removing that person's access should prevent new submissions and approvals, but it should not erase the history of deposits the person previously handled. Another authorized employee may need to complete a legitimate unfinished batch through a supported reassignment process. Reusing the departed employee's login to avoid disruption would undermine both access control and the audit trail.
A device replacement should preserve the same boundary. The bank can enroll the new device without treating every existing draft as a new payment. If drafts are stored locally, the product should explain whether they can be recovered securely and how the customer identifies work already submitted. If they cannot be recovered, staff should establish the original submission status before advising recapture.
Consumer mobile access needs an equally practical recovery path. A lost phone should not require the customer to remember an internal deposit identifier before obtaining help. Authorized support should be able to locate the submission using appropriate account and transaction details after authenticating the customer. The deposit history belongs to the bank relationship, not solely to the device on which the photograph was taken.
4. Capturing the front back and item data
The capture process should obtain the required front and back images and associate them with the correct amount, account and submission. The customer may enter an amount while the system reads values from the image. Those values should be compared and handled under the product's controls. A mismatch should not be resolved by silently trusting whichever source arrives first.
Mobile capture guidance should help the customer produce usable evidence: the whole check, sufficient contrast, legible content and the correct side. The bank should use its approved quality requirements and explain recoverable problems plainly. The image-exchange chapter covers the technical profile; here the focus is preventing the customer from submitting an unusable or mismatched representation in the first place.
A scanner can introduce different problems, including double feeds, jams, reversed sides, cropped edges and incorrect sequencing. The application should help the user reconcile the physical population to the captured population. If ten checks went into the scanner and only nine item records exist, the customer needs a controlled way to identify the missing item before submission.
Image quality does not establish authenticity or entitlement. A high-quality image of a counterfeit check remains a fraud concern. The bank should also preserve endorsements and any visible restrictions. An enhancement process that improves contrast while removing relevant marks can damage evidence rather than improve it.
A capture error should not become an invisible amount change
Suppose a contractor enters $3,650 but recognition reads $365. The app should identify the inconsistency and use the supported correction or review process. If the customer confirms the amount, the bank should retain the entered value, extracted value and relevant image. That history helps distinguish a customer input error from a recognition defect if an adjustment later occurs.
The same principle applies to account data. Recognition can misread a character or omit leading zeros. The bank should not allow casual manual repair to redirect an item toward another account without appropriate controls. The original capture and approved correction should remain linked. A corrected processing value should never replace the evidence of what the source showed.
The customer should also know whether a failed quality check occurred before or after bank receipt. “Image too dark; take another photograph” can be a safe pre-submission instruction. “Deposit outcome unknown” requires a different response. The interface should not use the same generic error message for both, because one invites recapture while the other requires status resolution.
Commercial batch screens should show the item count and total clearly enough to support review. A customer may recognize a missing payment from the physical remittance set even when the bank cannot. The system should allow correction within the permitted stage while preserving version history. Once the batch is submitted, changes should follow the bank's supported post-submission process rather than editing the submitted evidence in place.
Testing should include real capture conditions using approved test documents: different check sizes, faint printing, handwritten amounts, multiple endorsements, scanner jams and mobile orientation changes. The expected result is not merely a readable thumbnail. It is a correctly associated item record that can support acceptance, collection and later investigation.
Image repair cannot rewrite the source
Capture software may crop, deskew or adjust an image within its approved design. These operations should improve faithful representation, not manufacture missing information. If the amount or endorsement is outside the photograph, an enhancement algorithm cannot establish what the original says. The bank should request a valid recapture or use its approved review process instead of accepting a visually plausible reconstruction.
An entered amount should remain distinguishable from a recognized amount and the bank's accepted amount. Suppose the customer types $680 while the image shows $860. The bank needs an approved method to resolve that difference and communicate any changed deposit amount. It should not overwrite all three fields with $860 and lose the evidence that explains why the customer's receipt changed.
The image back deserves independent validation. A clear front does not establish that the endorsement was captured, and a reused back image can carry a restriction belonging to another item. The system should associate the image pair with the correct capture session and instrument. Review should focus on the actual evidence, with a controlled response when an endorsement or image association cannot be established.
An implementation test can deliberately swap the backs of two approved synthetic checks. The expected result should show how the bank's controls identify or investigate the mismatch; it should not claim that every such swap is automatically detectable. The bank should understand its detection coverage and use customer procedures, review and record controls to address the remaining risk.
5. Submission acceptance and customer status
The bank should distinguish a locally prepared deposit, a transmitted submission, a received request, an accepted deposit and a collected item. These stages may occur quickly in a normal journey, but they become separate during failures. A clear status model allows the customer and support staff to identify the safe next action without guessing from a spinner or an email delay.
A stable submission reference should be created and retained through the relevant stages. The customer should be able to use it to find the original request after an app restart. The bank should link it to the item and account records, including any technical retry. A new session or device should not make the original submission invisible.
Acceptance conditions should be explicit. A service may perform immediate automated checks and later review, or may reject certain submissions before they enter the deposit process. The bank must ensure the customer language and agreement match the actual design. A message saying accepted should not mean only that an image file exists in temporary storage.
The bank's collection process should use the accepted item population. A submission that is definitively rejected should not remain eligible for automatic collection through another queue. An accepted item awaiting a ledger response should not be collected again simply because the customer credit is delayed. The status model should separate collection intent from downstream posting recovery.
The contractor's spinning indicator
Return to the opening case. The app closed before the contractor saw the outcome. The bank should provide a history or status inquiry tied to the original submission. If it confirms acceptance, the customer should retain the paper according to the agreement and avoid another deposit. If it confirms rejection before collection, the bank can explain the permitted next action. If the result remains uncertain, the customer should receive clear instructions to seek resolution before presenting the paper again.
Support staff need access to the same authoritative status. They should not tell the customer to retry merely because the front-end history is empty. The backend may have accepted the request while a display update failed. A controlled support view should show the receipt, validation, acceptance and collection events with their native references and times.
The bank should also handle delayed notifications. An acceptance email can arrive after the customer has already contacted support or after a later rejection under a defined review process. Messages should identify the deposit and stage clearly, with a current status available through the service. Otherwise an old positive message can be mistaken for the latest outcome.
The API or file interface should document whether a retry with the same reference returns the original result, is rejected or follows another supported behavior. The bank should not assume that the vendor implements idempotency simply because it accepts a unique identifier. That behavior must be tested at the point where financial work is created.
A reliable status journey reduces both customer anxiety and duplicate risk. It lets the customer recover from a technical interruption while preserving the bank's control over one accepted deposit and one underlying check.
A receipt contract for uncertain submissions
The bank can make uncertainty manageable by defining a submission reference before the point at which the customer may lose the response. Under an illustrative design, the authenticated submission carries a stable request identity bound to the account and item content. A repeated request with the same identity retrieves or continues the original operation. If the content changes, the service should detect the conflict rather than silently treat it as the same accepted deposit. The exact API contract is bank-specific.
The customer's receipt should distinguish bank receipt, acceptance for deposit and expected processing. A status enquiry should return the authoritative state of the original request where available. If different systems disagree, the support view should show the unresolved condition and the team responsible for resolving it. The bank should not display a fabricated final rejection simply because the mobile application cannot currently reach the collection service.
The practical incident is familiar: the customer taps submit, the screen freezes, and the check remains on the kitchen table. Clear instructions should tell the customer how to check the original submission and avoid depositing the paper elsewhere while the outcome is uncertain. Those instructions protect both the customer and the bank. They should be available in the failure screen, not buried only in a lengthy agreement.
The backend must support that promise. If status is retained for only a short period, the bank needs another traceable inquiry route after that period. If a processor owns the acceptance record, the bank needs access to it during an incident. A well-worded message cannot compensate for a service that has no way to determine whether it accepted the payment.
6. Limits exposure and availability promises
RDC limits can apply by item, day, rolling period, account, customer or another defined dimension. They are product and risk controls, not universal limits imposed by Check 21. The bank should explain which limit is being applied and how pending or uncertain submissions affect remaining capacity. A customer should not see a higher available limit simply because a submitted deposit's final status has not yet arrived.
The bank should distinguish deposit acceptance limits from funds-availability treatment. A $10,000 channel limit, if chosen by a bank, says what the product will accept. It does not determine how long the bank may hold an accepted deposit or whether the check is genuine. Similarly, a more generous availability policy does not increase the permitted submission limit automatically.
Mobile image deposits do not simply inherit every Subpart B paper-check availability rule because the app uses a familiar deposit screen. The bank should establish the applicable legal scope and its RDC agreement, including any policy voluntarily applying comparable schedules. Other legal duties and customer-protection obligations still matter. The channel should state its actual availability promise clearly rather than use the phrase Regulation CC as a substitute for analysis.
A customer may submit at any hour while the bank's acceptance, review and processing schedules use defined cut-offs and banking days. Around-the-clock access to capture is not a promise of continuous settlement. The product should explain when a submission is assigned to a processing day and how weekends or holidays affect the expected outcome.
An agreement that voluntarily applies a comparable availability schedule should identify that commitment clearly. Staff need to distinguish a contractual promise from a statutory schedule while still honoring both where applicable. Customer service should retrieve the terms effective for the deposit, especially after a product change, instead of assuming that today's app disclosure governed every historical submission.
Capacity should include unresolved submissions
Suppose a business has an illustrative daily RDC limit of $50,000. It submits $35,000, but the response is uncertain. A dashboard that shows no completed deposits and allows another $50,000 can exceed the intended exposure if the first submission succeeded. The limit calculation should include the relevant pending commitments under the bank's design, with release only when the original outcome supports it.
A rejected deposit can free capacity, but the timing and basis should be defined. A local image-quality failure before submission differs from a bank review rejection after receipt. If the system frees capacity before establishing that no collection will occur, it may allow more exposure than intended. The bank should connect limit usage to the authoritative stage that creates or removes risk.
Limit increases should have appropriate authority and effective dates. A relationship manager may approve a temporary increase for a seasonal business, but the system should record its scope and expiry. The increase should not silently become permanent or apply to every account under the customer's group. Operational staff need to know the approved limit in effect for each submitted deposit.
Availability communication should be tested with partial acceptance and late review. If a batch contains five items and one is rejected, the customer needs to know which amount was accepted and the applicable expected availability. A message based only on the original batch total can overstate both the deposit and the usable funds. The bank should update the customer record without erasing the original submission history.
The practical goal is an honest promise. The customer can know what the channel will accept, when the bank expects to process it and when funds are expected to be usable, while the bank retains the ability to handle genuine exceptions under its disclosed and lawful framework.
7. Duplicate detection across channels and banks
RDC creates a distinctive duplicate risk because the original paper remains available after image submission. The customer can accidentally scan it twice, another employee can deposit it at a branch, or a person can intentionally present it through another institution. A bank should address duplicates at the submission, item and cross-channel levels rather than rely only on identical file detection.
Matching can use relevant routing, account, serial, amount and image information, together with prior deposit and payment history. Each field has limits. Check numbers can repeat, amounts can be identical across legitimate items, and a rescan can change the image. The bank should combine evidence and allow controlled review instead of treating one equal field as conclusive proof.
Within the bank, mobile, branch, ATM and commercial RDC histories should be considered according to the product's architecture and capabilities. A duplicate control limited to one mobile session will not detect paper later deposited at a branch. The bank should know the coverage of its controls and avoid promising that it can detect every deposit made at another institution.
External duplicate-notification services can support detection where used, but their coverage and timing are service-specific. They do not create a universal database of every U.S. check in real time. The bank should understand what population the service sees, what a match means and how staff should investigate before taking a financial action.
A duplicate alert is a decision point
A $3,650 item appears to match a mobile submission from the previous day. The earlier submission may have been accepted, rejected, corrected or left uncertain. The second deposit cannot be classified safely without that history. If the first was definitively rejected before collection, a supported new submission may be legitimate. If it was accepted, the second may create duplicate exposure. If it is uncertain, the bank needs to resolve the original before deciding.
The review should display both records and their images, account context, references and financial states. A reviewer should not be forced to decide from a single duplicate score. The system should retain the reason for any override and bind it to the item being released. An override of one false positive should not suppress future checks for every item sharing the same account or amount.
The bank should also prevent a customer from bypassing controls by changing a superficial field. A new filename, fresh photograph or slightly different entered amount can still represent the same instrument. At the same time, the bank should not block legitimate repeated payments merely because a payer reuses numbering. The control needs evidence and review appropriate to both risks.
When a duplicate has already produced two financial effects, prevention becomes recovery. The bank should identify both collection events and any customer credits before initiating the supported correction or claim. It should coordinate with the other institution where necessary and avoid multiple recoveries for one duplicate. The legal basis can depend on the actual paths and endorsements, as the next section explains.
Reporting should distinguish suspected duplicates, confirmed duplicate submissions, duplicate presentments and duplicate payments. Those are different outcomes. Counting every alert as prevented fraud exaggerates effectiveness and hides false positives. Accurate classification helps the bank improve its controls and explain real exposure.
8. RDC indemnity and restrictive endorsements
Regulation CC §229.34(f) addresses a specific RDC indemnity. In broad terms, a depositary bank that accepts an electronic image without receiving the original, receives settlement or other consideration for the electronic check or substitute check, and does not receive its return may owe indemnity to a depositary bank that later accepts the original and suffers the specified duplicate-payment loss. The provision's conditions and loss rules must be applied to the actual case.
The later paper-deposit bank cannot make that indemnity claim if the original it accepted bore a restrictive endorsement inconsistent with the means of deposit. This is why endorsement evidence matters. The rule is not a blanket statement that the first bank always pays, the second bank always loses, or a particular printed phrase guarantees protection. Regulation CC §229.34.
The bank's customer instructions should specify its required endorsement and original handling. A restriction can help identify the intended deposit method and support the relevant analysis. It does not make duplicate deposit physically impossible, and it should not be described as an automatic liability waiver for every circumstance. The bank still needs to assess the actual item, deposit paths and financial effects.
The Federal Reserve has a specific RDC adjustment investigation type with conditions concerning the involved item paths and settlement. A bank using that process should follow the current service requirements rather than assume it applies to every cross-bank RDC dispute. The operational route is separate from the underlying legal analysis. Federal Reserve RDC adjustment type.
Reading the original before deciding the claim
Suppose Bank A accepted a mobile image and received settlement with no return. Bank B later accepted the original paper and incurred a loss because the check had already been paid. Bank B should establish the actual facts required for the indemnity and preserve the original's endorsement. If the paper carried a restriction inconsistent with Bank B's deposit method, that fact can change the availability of the specific claim.
The bank should not rely on a customer recollection that the check was endorsed correctly. The original or reliable image evidence matters. It should also establish whether the earlier event was actually an RDC deposit, whether the first bank received the relevant settlement and whether the item was returned. A mobile upload attempt that never became an accepted, settled collection does not establish all the same conditions.
The investigator should identify the loss being claimed. A later bank may have credited its depositor, paid out funds or incurred another defined loss. The claim should connect the duplicate-payment facts to that loss under the applicable provision. A file match alone does not quantify the recoverable amount or resolve defenses.
Customer treatment should be coordinated with the interbank case. If a depositor has received two credits, the banks need to determine their respective actions under the relevant agreements and law. The indemnity analysis does not itself authorize every possible debit to every customer. The bank should keep customer authority, interbank liability and actual recovery separate in the case record.
For implementation, the lesson is concrete: retain the original handling instructions, endorsement evidence, acceptance and settlement history, and any return. Those records make it possible to apply the rule accurately. A generic RDC flag without the supporting facts is insufficient for a defensible claim.
9. Original-paper retention storage and destruction
The original paper remains a potential payment instrument and a source of evidence after remote capture. The customer should handle it according to the bank's RDC agreement and applicable requirements. The bank must define when it should be marked, how long it should be retained, how it should be secured and when destruction is permitted. There is no universal retention period that every RDC customer can safely copy from another bank's app.
A retention instruction should be clear enough to follow. “Keep the check until processed” is weak if the customer does not know whether processed means uploaded, accepted, posted or paid. The product should identify the relevant confirmation and any additional retention period under its terms. It should also explain what to do if a dispute or bank request arises before scheduled destruction.
Storage should prevent accidental redeposit and unauthorized access. A commercial customer can separate accepted RDC originals from unprocessed receipts, control access and maintain a record of their disposition. A consumer needs practical instructions suited to home use. The bank should avoid a workflow that leaves accepted originals mixed with new checks awaiting deposit.
Destruction should make the original unusable and protect the information it contains. The bank's procedure should identify the approved timing and method rather than assume that throwing the check into ordinary waste is sufficient. Where a legal hold, investigation or request for the original applies, routine destruction should be suspended under the relevant process.
A filing cabinet can defeat a good digital control
A business scans checks in the morning and places them in a tray labelled bank deposits. Another employee collects that tray for a branch visit in the afternoon. The digital application may have processed every item correctly, yet the physical workflow creates duplicates. The customer needs a clear separation between unsubmitted paper, submitted items awaiting confirmation and accepted originals retained for evidence.
The physical status should follow the authoritative digital outcome. Marking a check as deposited before the bank receives it can confuse recovery if the submission fails. Leaving a confirmed accepted original unmarked and mixed with new work can encourage a second deposit. The bank's instructions should explain how to handle both situations without suggesting that a mark itself proves acceptance.
For commercial customers, a retained-paper inventory can link each original to its deposit reference, acceptance date and planned disposition. The level of detail should fit the volume and risk. A small office may use a controlled log, while a larger processor may need a more formal tracking system. The objective is retrievability and duplicate prevention, not paperwork for its own sake.
The bank should test a request for an original during onboarding or review where appropriate. Can the customer find the correct check promptly? Is access restricted? Can it identify whether the paper was destroyed under the schedule? A policy document saying originals are retained is weaker evidence than a working retrieval process.
The bank also needs a plan for relationship termination. A customer losing RDC access may still hold originals from earlier accepted deposits. The termination communication should preserve its obligations concerning those items and explain how to respond to later inquiries. Closing the channel should not imply that the paper can be freely redeposited or immediately discarded.
An original is requested after routine filing
Suppose the bank requests the original for an investigation while the customer still holds it under the agreed retention procedure. The request should identify the specific item, approved delivery method and handling instructions. The customer should not send an untracked envelope to an address obtained from an unverified message. The bank also needs to record receipt and prevent the original from entering a fresh deposit stream when it arrives.
For a business, the original's location should be retrievable without opening every retained envelope. A batch reference, item reference and storage index can be sufficient in an appropriate design. The customer should limit who can remove an original and record when it is sent to the bank. This is particularly useful when an accounts-receivable team and a treasury team share responsibility for deposits.
If the customer already destroyed the original in accordance with the bank's applicable instructions, operations should record that fact and determine what other evidence is available. Staff should not assume misconduct or invent a statutory retention obligation after the event. If the customer destroyed it contrary to the agreed procedure, the bank must assess the actual contractual and evidentiary consequences rather than apply an automatic loss outcome unsupported by the facts.
A retention-policy change should state which deposits it affects. Extending retention for new deposits does not recreate originals already destroyed under prior instructions. The bank should coordinate updated customer communications, app text and support procedures. The historical instruction version can matter in a later dispute, so it should remain available with the deposit's acceptance context.
10. Review rejection and post-acceptance exceptions
An RDC review can identify an ineligible instrument, unreadable image, amount mismatch, endorsement concern, possible duplicate or another issue. The bank should state whether the submission was rejected before acceptance, accepted but held for a defined review, or already sent for collection. These stages determine the safe next action and the customer message.
A pre-acceptance rejection may allow the customer to correct and submit under the product's procedure. A post-acceptance problem may require the bank to repair or investigate the existing item. An uncertain collection outcome should not be treated as a fresh rejection. The bank must know whether the original financial intent has already been released before advising another deposit.
The rejection reason should be useful and accurate. “Unsupported item type” differs from “image unreadable” and from “possible duplicate under review.” A customer should not be told to alter the document to overcome an eligibility restriction. A bank may request a better image of the same original, but it should not encourage changes to the underlying instrument.
If the bank changes the accepted amount after review, it should retain the original submission, evidence and customer communication. The customer needs to understand whether the correction concerns its entered amount or the bank's capture. A silent change can cause reconciliation problems for a business and a complaint from a consumer who expected a different credit.
A partial business batch needs an item-level answer
A business submits twelve checks totalling $28,000. Eleven are accepted and one $2,200 item is rejected under the service's supported process. The bank should show the accepted $25,800 population and identify the rejected item. It should not tell the customer the whole batch failed if collection has begun for the other eleven, nor show the full $28,000 as accepted.
The customer's internal records may initially contain the original batch total. The bank's report should support a controlled adjustment to the deposit allocation. The rejected item remains a business receivable or uncollected instrument under the customer's accounting treatment. The bank should not represent rejection as a refund if no financial collection occurred.
If the rejected item is later resubmitted, it should be linked to the original submission history. The bank should establish that the earlier item did not already enter collection. The customer should receive a new permitted submission reference where the product requires it, while the bank preserves the same underlying instrument identity for duplicate controls.
Review queues should have ownership and operating targets consistent with the product promise. A deposit accepted for same-day review should not remain invisible over a weekend because a vendor queue lacks bank monitoring. The bank needs escalation for aged items and a customer communication process when the expected treatment changes under the agreement.
The exception closes when the customer knows the actual result and the bank can account for the item and any financial effect. A rejection email alone is insufficient if the ledger still shows a credit or the item remains in an outgoing collection queue. The bank should reconcile those systems before treating the event as resolved.
11. Collection settlement and customer posting
Once the bank accepts the RDC item for collection, it enters the check-processing lifecycle described in Chapters 36 and 37. The remote channel does not create a different kind of settlement money. The bank routes the electronic check through its approved collection arrangement, receives the relevant reports and reconciles the financial entries. The customer's deposit posting remains a separate account event.
A mobile confirmation is not a paying-bank authorization response. The paying bank may receive presentment later through the check exchange. The depositary bank should not label its own acceptance as payer approval. The distinction is especially important when customers compare mobile deposit with an instant account-to-account payment and assume the same finality.
The bank may provide provisional customer credit before receiving collection settlement. That creates exposure if the customer uses the funds and the item is unpaid or later subject to a valid claim. Treasury and finance need the actual collection and availability facts, including unresolved submissions and returns. The bank should not use the app's success count as a cash forecast.
The settlement relationship may involve the bank's Reserve Bank account, a correspondent or another agreed arrangement. The RDC vendor can prepare files or reports without holding the settlement obligation itself. Architecture diagrams should identify where money moves and which bank accounts evidence the movement, rather than drawing value as though it travels inside the uploaded image.
A customer credit failure is not a reason to collect again
Suppose the bank accepts and collects the contractor's $3,650 item, but the customer posting fails because of a core interface problem. The bank should repair the customer effect under its approved accounting controls. Asking the contractor to take another photograph would address the wrong failure and could cause duplicate payment by the drawer.
The deposit record should show acceptance, outgoing collection, settlement evidence and the failed posting attempt. The repair should retain the original item and create the appropriate correcting or retried ledger action. It should not create a second customer deposit identity merely because the core requires a new technical request identifier.
The reverse can also occur: the customer is credited while the item never leaves an internal review queue. Operations must establish why collection is missing and take the supported action. If the item is ineligible, the bank needs the proper customer and accounting treatment. It should not leave a credit indefinitely supported only by an image that was never accepted for external processing.
Business customers need reports that distinguish deposit acceptance, financial posting and returns. Some banks provide intraday information before the final daily report. The definitions should be clear enough for the customer's reconciliation process to avoid counting the same deposit twice. A later report can confirm or update an earlier event without representing another receipt of money.
The bank should preserve the chain from remote submission to settlement even after the customer deletes the app or the business replaces its scanner. The channel device is not the long-term system of record. The bank's evidence should support a later investigation without requiring the original customer session to remain available.
12. RDC fraud monitoring and financial-crime controls
RDC monitoring should combine the item with the customer's account and channel behavior. Relevant signals can include unusual value or frequency, repeated similar instruments, multiple accounts receiving related items, unexpected capture locations, rapid movement of proceeds and repeated quality or duplicate exceptions. These signals require context and review; none is a universal proof of fraud.
The bank should understand whether a commercial customer deposits on behalf of others and whether that activity is within the approved relationship. A remote-capture service can obscure the physical origin of instruments if the bank sees only a file. Customer due diligence and ongoing monitoring should preserve visibility into the actual business model. The bank should not assume that a domestic deposit account means every capture location or underlying payer relationship is domestic and ordinary.
Fraud controls should be coordinated with access security. A compromised user can submit altered or fabricated items through an otherwise valid customer relationship. A legitimate user can also be deceived into depositing a bad check. Authentication establishes the channel actor; it does not establish the legitimacy of the instrument. The bank should retain both dimensions in its review.
BSA reporting and sanctions processes remain separate from deposit acceptance and ordinary check returns. The bank should assess applicable obligations through its controlled functions and preserve confidentiality. A sanctions alert is not an ordinary availability hold, and a SAR is not a payment-reversal mechanism. Chapter 38 established those distinctions; RDC adds channel and custody evidence to the analysis.
Monitoring should reveal changes in how the service is used
A business that normally deposits a few customer checks begins submitting many sequentially numbered instruments from unrelated accounts. The bank should compare that pattern with the expected business and ask focused questions. It should not rely only on whether each item is below the daily limit. Limits control exposure, while monitoring evaluates the nature and pattern of activity.
Another customer submits checks from several devices shortly after changing contact details. The bank may need to assess account takeover and the legitimacy of the new devices. It should preserve the access and submission history while ensuring the genuine customer has a supported way to contact the bank. Blocking a device without establishing pending deposit outcomes can leave financial work unresolved.
The monitoring model should include rejected and uncertain attempts where relevant. Repeated failed submissions can reveal abuse or a usability problem. If the bank sees only accepted deposits, it may miss a pattern of customers changing amounts to bypass controls or repeatedly attempting to deposit the same item. Review should distinguish suspicious behavior from ordinary capture difficulty.
The bank should avoid overstating the effectiveness of an image-fraud tool. A vendor score can support prioritization, but the bank needs to understand its inputs, limitations and handling of false positives. A model trained on one channel or customer population may not perform the same way on another. Governance should connect the score to a defined action and review process.
Customer education is part of the control. Clear instructions about one deposit, status inquiry and original handling can prevent accidental duplicates. Specific warnings about overpayment and employment-check scams can help customers recognize deceptive instructions. The bank should make these messages timely and understandable rather than rely on a generic fraud disclaimer after the customer has already sent the proceeds elsewhere.
13. Reconciliation reporting and customer support
RDC reconciliation begins with the submitted population and follows it through receipt, acceptance, collection, settlement, customer posting and any exception. The bank needs both item and batch views. A batch can be partly accepted, one item can be returned later, and a posting can fail independently from collection. A total-only report will not explain these differences.
The remote channel should retain the stable deposit reference and map it to native collection and settlement references. Customer support can then begin with the reference shown in the app and reach the underlying evidence. A commercial customer should not be required to know an interbank cash-letter number to investigate a missing deposit.
Customer reports should distinguish submitted, accepted, rejected, adjusted and returned amounts according to the product's actual terminology. The bank should avoid issuing two reports that use the same status word for different stages. If an intraday report is provisional, that should be clear. The customer's accounting interface needs enough information to update rather than duplicate the earlier event.
Accounting should preserve the original deposit and later financial changes. A corrected amount, return or recovery is not a new receipt from the payer. The bank should record the actual customer and settlement effects under its approved policy and retain the case relationship. Where proceeds have been withdrawn, the resulting exposure should remain visible rather than hidden by an uncollected customer debit.
A support answer should be based on the authoritative stage
The contractor calls and says the deposit has disappeared. Staff should locate the original reference and establish whether the issue concerns the display, acceptance, collection or posting. A front-end history problem can be repaired without asking for another deposit. A genuine rejection requires a clear explanation of the permitted next action. An uncertain outcome requires ownership and follow-up.
Support should also explain what to do with the original paper. If the bank needs it for investigation, the customer should receive secure delivery instructions through the approved channel. Staff should not ask the customer to send full check images through an unapproved messaging app because it seems faster. The evidence is sensitive and may be needed for a formal claim.
A business customer may report that its ledger differs from the bank's deposit total. The bank should provide the accepted item population, corrections and returns, with identifiers that support allocation. It should not assume that the customer's mismatch is a bank error, but it should supply enough evidence to locate the cause. A batch total alone is rarely sufficient when one item was rejected or adjusted.
Operational reporting should identify aged uncertain submissions, accepted items without collection evidence, unmatched settlement, failed customer postings and unresolved original requests. These categories point to different actions and owners. A single RDC error count may be useful for a headline but should not replace the queues needed to resolve the work.
The bank should also retain customer communication history. If support advised a redeposit that later caused a duplicate, that fact matters to the investigation. Accurate records allow the bank to address both the financial effect and the process weakness. The purpose is to improve the service and apply the correct treatment, not to reconstruct responsibility from incomplete recollections.
Support evidence after an amount correction
A customer may remember the amount entered in the app rather than the amount ultimately accepted by the bank. Support should be able to display both, together with the source image and the correction notice. This allows staff to explain an $860 accepted deposit that began as a $680 entry without suggesting that a separate $180 payment was collected. The difference is a correction to the same instrument record.
The bank should also establish which version reached downstream collection. If the original amount was never released, there may be no interbank amount adjustment. If an incorrect amount entered collection, a later correction requires the appropriate financial and service process. The customer interface should not infer that every edit produces a settlement entry. It should show the actual sequence supported by the bank's records.
A complaint about the correction deserves review even when the system's selected amount appears plausible. Staff should retrieve the unaltered source and the approved repair evidence, then apply the relevant customer and processing obligations. This gives the customer a reasoned answer and prevents a recognition-system output from becoming an unquestionable authority over what the instrument actually states.
14. Vendor resilience and production readiness
An RDC service depends on more than the mobile app or scanner. It can involve authentication, image capture software, recognition, risk scoring, deposit orchestration, item processing, core posting, exchange connectivity, archives and notifications. The bank should identify the critical dependencies and their operational owners. A vendor outage can affect one stage while other stages continue.
Business continuity should distinguish new deposits from submissions already in flight. If the bank disables the channel during an incident, it still needs to establish the outcome of requests received before suspension. The recovery plan should preserve evidence and prevent automatic replay from creating duplicates. Restoring the login screen is not the same as restoring safe deposit processing.
Vendor arrangements should cover access to item history, images, acknowledgements and reports during incidents and after termination. The bank may need to investigate a deposit long after changing providers. Data export and retention should preserve the relationships among records, not merely deliver a folder of unindexed images. The bank's responsibility to its customer continues beyond the vendor contract's operational cutover.
Testing should include the actual channel and back-end configuration. A mobile release can change camera behavior, image compression or session handling. A scanner-driver update can alter sequencing. A risk-service timeout can change acceptance behavior. Each should be assessed for its effect on evidence, customer status and financial work.
The most important outage test is the ambiguous one
A useful test interrupts the connection after the bank receives a submission but before the customer receives the result. The customer then restarts the app and attempts to deposit again. The expected behavior should preserve the original submission, provide a supported status path and prevent duplicate financial intent under the product's design. This is more meaningful than a test where the request never leaves the device.
Another test lets collection succeed while the notification service fails. The bank should not create another deposit to regenerate a message. It should send or repair the notification using the existing deposit record and accurate current status. If a delayed message could mislead the customer, the communication logic should identify its stage and reference clearly.
A commercial resilience exercise can simulate a scanner jam midway through a batch. The user should be able to identify which physical checks correspond to captured records and which were not captured. The application should prevent the user from blindly rescanning the whole stack into a second accepted batch. Training and interface design should support this recovery together.
The bank should define release gates around financial integrity. Unexplained duplicate deposits, wrong-account credits, missing accepted items or unreconciled settlement should stop a rollout under the bank's approved criteria. Cosmetic defects may have different treatment, but financial ambiguity should not be dismissed because the app appears responsive.
Production readiness also includes support and customer instructions. Staff should know how to find a submission, distinguish rejection from uncertainty, request an original and explain the availability policy. A technically successful deployment without those capabilities leaves the most consequential decisions to improvisation.
A processor outage that crosses the cut-off
Assume a business submits a batch before the bank's disclosed RDC cut-off. The bank records receipt, but a downstream processor outage delays collection release. The bank should determine the accepted deposit day and customer commitment from its actual terms and applicable obligations. It should not silently reclassify the original submission as late merely because an internal transfer completed after cut-off.
At the same time, treasury must forecast collection from the actual downstream acceptance and settlement schedule. The bank may owe the customer a particular availability treatment while receiving settlement later than planned. That difference is a liquidity and service issue to manage, not a reason to rewrite the customer's timestamp. The channel and settlement calendars must remain connected but distinct.
Recovery should identify the accepted population waiting for release. Operators should not ask customers to resubmit every check if the bank already has valid records ready for controlled continuation. Where data is genuinely incomplete, the bank should explain the affected items and the supported next action. A broad resubmission request can turn a limited outage into a duplicate-deposit incident.
The incident review should quantify accepted but unreleased value, delayed settlement, customer commitments, communication failures and any duplicate attempts. Those measures explain the actual impact better than uptime alone. A service can recover its servers quickly while leaving customers uncertain about their deposits for much longer. Production readiness includes the ability to resolve that uncertainty at item level.
15. Worked cases and channel testing
Case A — the app closes after submission. A contractor photographs a $3,650 check, loses the app response and considers depositing the paper at a branch. What should the bank provide?
A status inquiry tied to the original submission and a clear instruction based on the established outcome. If accepted, the customer should follow the original-retention instructions and avoid another deposit. If definitively rejected before collection, the supported next action can be explained. If uncertain, the bank should own the inquiry. A generic try-again message is not sufficient where financial work may already exist.
Case B — two employees handle the same paper. One employee scans a batch, while another later takes the originals to a branch. Which controls are relevant?
The customer's physical workflow, marking and storage instructions, shared deposit history and the bank's cross-channel duplicate controls. The bank should establish the actual first and second outcomes before applying a correction or claim. The case is not solved merely by showing that the scanner application worked correctly. Training should demonstrate the separation of unprocessed, uncertain and accepted originals.
Case C — daily capacity resets after a timeout. A business has a $50,000 illustrative daily limit and an uncertain $35,000 submission. The app shows the full limit available again. What is the exposure?
The first submission may have succeeded, so another full-limit deposit could exceed the intended risk capacity. The bank should define how pending and uncertain submissions consume capacity and when it can be released. The test should include delayed acceptance and rejection results, ensuring that capacity is neither freed prematurely nor permanently trapped after a definitive failure.
Case D — the paper has a conflicting restriction. A bank accepts an original that bears an endorsement inconsistent with the deposit method. It later seeks RDC indemnity after duplicate payment. What must the investigator consider?
The specific restrictive-endorsement limitation in §229.34(f), along with all other claim conditions and loss facts. The bank should preserve the original evidence and avoid assuming that later acceptance of paper automatically creates a recoverable claim against the first image-deposit bank. The customer and interbank financial positions must be analyzed separately.
Case E — collection succeeds but the customer is not credited. The RDC item appears in accepted collection and settlement records, while the core posting failed. Should the customer submit again?
No. The bank should repair the customer posting under approved controls using the original deposit and financial references. Resubmission addresses the wrong stage and can duplicate collection. The test should verify that ledger recovery uses one business deposit even if the technical posting request receives a new identifier.
Case F — originals destroyed during a claim. A business follows its ordinary destruction schedule after the bank requested an original for an open investigation. What should the service design have addressed?
The need to suspend routine destruction when an investigation, legal hold or specific bank request applies under the agreement and law. The bank should make the instruction clear and preserve delivery evidence. The customer's process should identify affected originals and prevent them from being destroyed with routine retained work. The consequences require the actual facts and agreement; the chapter does not invent an automatic liability result.
Testing one deposit through every recovery point
An end-to-end RDC test should begin with an authenticated user and approved test check, then follow capture, submission, acceptance, collection, settlement, customer posting and original handling. At each boundary, interrupt the process and identify the safe recovery. The expected result should state whether the customer may recapture, must inquire, or should wait for a defined bank action.
The test should also inspect what the customer and support staff see. A backend can preserve perfect idempotency while the customer receives confusing instructions that lead it to another bank. The bank cannot control every external action, but it can provide accurate status and clear original-handling guidance. Good customer communication is therefore part of duplicate-risk control.
For business RDC, include multiple accounts, partial batches, amount corrections, approval changes and scanner replacement. Verify that the correct legal customer and account receive the accepted value. For mobile, include session expiry, app restart, camera recapture and delayed notifications. These are different channel conditions with the same underlying requirement: one explainable deposit and no accidental second collection.
Partial acceptance with a customer amount correction
A business sends three illustrative checks for $1,200, $860 and $440, expecting a $2,500 batch. The middle item was typed as $680 in the draft, and the third lacks a usable back image. Under a product that supports item-level acceptance, the bank may accept the first two for the supported $2,060 total while routing the third to a definitive pre-collection rejection or review, as the actual process provides. The customer needs an itemized outcome explaining both the amount correction and the unaccepted item.
The batch should not retain a misleading single success status for $2,500, nor should the bank reject and resubmit the two accepted items merely to obtain one clean batch total. The accepted-item records should drive customer credit and expected collection. The unresolved or rejected item should have its own next action, and any new capture should link to the original history sufficiently to prevent an accidental duplicate.
Ask the learner to explain the limit usage, availability communication, original-paper handling and reconciliation for each item. The answer should use the bank's actual acceptance model and illustrative policy, with no invented universal RDC rule. This case brings the channel's essential controls together: correct source evidence, honest status, one supported financial effect and a recoverable history when only part of the customer's request succeeds.
16. Role checklist and learning closure
The Business Analyst defines acceptance, uncertainty, limits, original handling and the relationship between remote submission and collection. The Product Owner ensures the mobile or commercial promise matches the actual agreement and processing model. Legal and compliance teams establish availability treatment, endorsement instructions, indemnity analysis and the relevant customer protections without treating every electronic deposit as the same legal product.
The Architect and Developer preserve one item identity across devices, retries, review and financial processing. The Tester exercises ambiguous failures, cross-channel duplicates, partial acceptance and posting recovery. Operations owns uncertain submissions and the evidence needed to resolve them. Fraud and BSA teams combine channel activity with customer and instrument context while preserving their separate reporting controls.
Finance and treasury reconcile accepted deposits to actual collection and settlement. Customer service gives a supported answer about the original submission and tells the customer what to do with the paper. The customer's own document workflow is part of the service, especially where several employees handle receipts.
Chapter 40 now moves to bank-operated or outsourced lockbox processing, where receipt handling and remittance data are central. It also explains the point where an eligible check becomes the source document for an ACH debit, changing the processing and rights framework.
Remote capture works when the customer can recover from a failed screen without creating another payment, and the bank can prove what happened to the first one.
Authoritative references
Public sources checked on 6 September 2026. Older explanatory sources are used for stable operating concepts, with current law and service requirements controlling. No universal RDC limit, original-retention period, mobile availability schedule or automated fraud guarantee is asserted.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.