MyData Transfer Security (MyData Transfer Security Guide, Sep. 2023)
1. Overview
A. Definition
A guide that organizes the administrative, technical, and physical safeguard standards for controlling the risks that arise when personal (credit) information is transferred between institutions at the data subject's request under MyData (the personal credit information management business). It commonly requires both the sender (information provider) and the receiver (MyData operator) to designate a protection officer and to implement access management, transfer-channel protection, incident response, and so on.
The essence of MyData is to gather "my information," scattered across many institutions such as banks, card companies, insurers, and telecom carriers, into one place based on the data subject's right to request transfer, and to use it for integrated inquiry, analysis, and recommendation. Previously, a user had to visit each institution's screens one by one to check their information, but MyData changed this into a structure in which an operator pulls the provider's data directly through a standard API. The benefit of this structure is clear, but the fundamental risk is precisely that large volumes of sensitive personal credit information travel between institutions constantly and automatically. The very moment the data moves is the risk window for leakage, tampering, misdelivery, and reuse, so controlling the entire transfer path end-to-end is the precondition of trust in MyData.
B. Background and Necessity
After MyData was fully launched in 2022, the number of participating institutions and the transfer traffic exploded, creating a structure in which a single participant's security gap can collapse the trust of the entire ecosystem. Even if the average transfer volume of a single API call seems small, when hundreds of institutions periodically exchange the asset, income, payment, and loan records of tens of millions of people, the overall exposure surface becomes incomparably wider than that of the earlier individual services. In particular, because the target information is property-related sensitive information such as assets, credit, and income, a leak immediately leads to monetary damage through voice phishing, loan fraud, and the like, and once leaked, information is virtually impossible to recover.
Moreover, a transfer is a bilateral act in which the "giving side" and the "receiving side" are separated, so it is meaningless for only one side to be secure. No matter how thoroughly the sender encrypts the data, if the receiver neglects access control, the data is exposed immediately after receipt, and vice versa. Accordingly, this guide was created when supervisory and related agencies concretized the obligation to secure safety under the Credit Information Act and the Personal Information Protection Act to fit the special context of MyData transfers, unifying the standards so that the sender and receiver bear the same level of protection responsibility. In other words, the guide is not the creation of a new regulation but has the character of a practical commentary and checklist that projects existing legal obligations onto the transfer scenario.
C. Characteristics
MyData transfer security has three characteristics compared with general information protection measures. First, constancy. Whereas data movement in earlier services was intermittent batches, MyData's periodic and ad hoc transfers occur automatically around the clock, so controls must also be operated constantly. Second, standardization. Because there are many participating institutions, security cannot be aligned through individual negotiation, so standard APIs and common safeguards level the security baseline. Third, data-subject centrality. Since every transfer is grounded in the data subject's transfer request, accurately reflecting the authenticity, scope, and withdrawal of the request itself becomes a security requirement.
2. The Overall Structure of MyData Transfer Security
MyData transfer security is composed of four axes: "who is responsible (management)," "who accesses (access control)," "what moves and how (transfer and storage protection)," and "what to do if it stops or blows up (availability and incident response)." These four axes are not independent but are linked like a chain, so the strength of the weakest link determines the overall security level.
flowchart LR
subgraph Provider["Information provider (sender)"]
DB1[(Personal credit information)]
AUTH1["Authentication & access control"]
end
subgraph Channel["Transfer channel"]
TLS["mTLS encrypted channel"]
TOK["Access token (least privilege, short-lived)"]
end
subgraph MyData["MyData operator (receiver)"]
AUTH2["Authentication & access control"]
DB2[(Collected information storage & encryption)]
end
US["Data subject (transfer request)"] --> MyData
DB1 --> AUTH1 --> TLS
TOK --> TLS
TLS --> AUTH2 --> DB2
CPO["Protection officer (CPO): policy & inspection"] -.oversight.-> Provider
CPO -.oversight.-> MyData
As the figure shows, a transfer starts from the data subject's transfer request; it passes through authentication and access control at the provider's database, is delivered to the receiver over an encrypted channel (mTLS), and is then stored safely under access control on the receiver's side. This entire flow is overseen by both sides' protection officers through policy and inspection. Most of the guide's requirements map onto each segment of this figure — Chapters 3 to 5 below cover management (CPO), access management, and transfer/storage/availability respectively.
What is especially important in this structure is that the access token is managed separately from the channel. The token issued in response to a transfer request is a key that holds "which data subject's, what scope of, and until when" information may be fetched, so the entire process of issuing, verifying, and revoking the token becomes the central axis of transfer security. If the channel (mTLS) guarantees "the safety of the passage," the token guarantees "the safety of authorization," and the two are complementary — a transfer cannot be trusted on either one alone.
3. Designating a Personal Information Protection Officer (CPO) for Transferred Data
Safeguards start, before technology, from "who takes responsibility and manages." No matter how sophisticated the technical controls are, if there is no party to oversee them, inspect them periodically, and take command during incidents, the controls are installed and then left to rot and incident response drifts. That is why the guide requires a clearly designated Personal Information Protection Officer (CPO) who governs the transfer function to oversee the establishment and compliance inspection of transfer security policy and the response to breach incidents.
For a CPO regime to be effective, substantive authority and independence are key. If the protection officer is subordinated to a line (sales/service) department, it is hard to resist pressure to relax security controls, which yields to convenience demands such as "speed up the transfer" or "cut the authentication steps." Therefore the CPO must be in a position to report directly to management and be allocated budget, personnel, and organizational authority. This is consistent with the intent of ISMS-P and the Credit Information Act, which emphasize the independence of the CISO and CPO.
In addition, because a transfer is a bilateral act, both the sender and the receiver must clearly establish a responsible party. If only one side has a responsibility regime, when an incident occurs the question of "whether it is a problem at the provision stage or the receipt stage" becomes blurred and response is delayed. In practice, both sides' CPOs agree in advance on transfer specifications and security requirements and establish governance to cross-check logs and inspection results periodically. For example, if an anomalous transfer is detected at a particular operator, the matter is not closed on the receiver CPO's judgment alone; a cooperative procedure is documented in advance to notify the provider CPO and jointly investigate and block it.
Furthermore, the CPO's role does not stop at being a "firefighter" after an incident occurs. It is more important to review the transfer scope, retention period, and purpose of use at the planning stage of a new service and, through prior controls such as a Privacy Impact Assessment (PIA), to remove risks at the design stage. The recovery cost and loss of trust after an incident breaks out are incomparably larger than the cost of control at the design stage. In this sense, designating a CPO is a device that embeds security into the organization as a "question asked at all times."
| Item | Content | Reason |
|---|---|---|
| CPO designation | Designate a protection officer who oversees transfer work and clarify responsibility | Prevent the absence of a party to operate and inspect controls |
| Role | Establish transfer security policy, inspect compliance, oversee breach-incident response | Maintain the continuous effectiveness of installed controls |
| Independence | Substantive authority and independence, a direct-to-management reporting line | Resilience against the line's pressure to relax controls |
| Both-side regime | Designate a responsible party on both sender and receiver sides and a cooperation procedure | Clarify responsibility and enable joint response during incidents |
4. Access Management for the Personal Information Processing System Handling Transferred Data
The principle of access management can be summarized as "only the people who need it, only as much as they need, and leaving a trace." Because transferred data is ultimately stored and processed in the personal information processing system, if one cannot control who accesses this system and to what extent, encryption and transfer protection become meaningless.
flowchart LR
A["Minimize access rights & separate duties"] --> B["Multi-factor authentication (MFA)"]
B --> C["Retain access logs & prevent tampering"]
C --> D["Anomaly detection & automatic blocking"]
D -.feedback.-> A
First, least privilege and separation of duties. Processing-system rights are narrowed to the scope strictly necessary for the job, and developers and operators, as well as read rights and change rights, are separated. The reason is to confine the damage by narrowing the scope of information reachable through an account even if it is compromised. Rights are not granted once and left alone; they must be periodically revoked and reviewed in line with hiring, departure, and job change, because neglected idle accounts and excessive rights are the most common entry points for actual incidents.
Second, strengthened authentication. Because single-factor password authentication is vulnerable to phishing, reuse, and brute force, in the MyData transfer context multi-factor authentication (MFA) is applied to human logins, and mutual TLS authentication (mTLS) is combined with short-lived access tokens for machine-to-machine API calls. The core of practice is to issue tokens with a short validity period and a narrow scope of authority (scope) so that damage is minimized even if a token is stolen.
Third, access-log management and anomaly detection. All access and processing actions are recorded as access logs and kept together with tamper-prevention measures (hashing, integrity protection, separate storage). Access logs are not only the basis for after-the-fact tracing but also the input for real-time detection of anomalous behavior such as a large-scale late-night query or a transfer request that greatly departs from the usual pattern. For example, the system is designed so that if one account generates transfer requests hundreds of times its usual volume in a short time, automatic blocking and alerting are triggered, and the result is fed back into the rights policy to strengthen controls.
These three controls complement one another. Least privilege narrows the "scope of damage," MFA lowers the "probability of intrusion," and access logs and anomaly detection handle "detection and after-the-fact tracing." Only by designing a defense-in-depth structure in which, even if one is breached, the rest absorb the damage, can one prevent a single control failure from leading directly to mass leakage.
| Item | Content |
|---|---|
| Access rights | Least privilege and separation of duties, periodic review of grant and revocation of rights |
| Authentication | MFA (human), mTLS and short-lived tokens (machine), session and account management |
| Access logs | Retain access and processing logs and prevent tampering, store separately |
| Control & detection | Access-control system, anomaly monitoring and automatic blocking |
5. Personal Information Management and Disaster/Calamity Preparedness
The safety of transferred data is only complete when both in transit and at rest are protected. The transfer channel is encrypted with TLS/mTLS to prevent man-in-the-middle attacks, and the data stored after receipt is encrypted so that plaintext is not exposed even in case of storage-media theft or insider leakage. If only one side is protected — for example, if transfer is encrypted but storage is left in plaintext — the most vulnerable point determines the entire security posture.
Added to this are integrity verification (digital signatures, hashing), which guarantees that the data was not altered in transit, and DLP-type controls, which detect and block mass-leakage attempts. In particular, in MyData, misdelivery — being "transferred to the wrong person" — is also fatal, so a control that re-confirms the receiver's identity and authorization just before transfer is important.
Meanwhile, because MyData is a service in which many institutions are connected in real time, availability itself becomes a security requirement. If a particular provider's system halts due to a disaster, the entire transfer chain that depends on that institution's information is affected. Therefore service continuity is secured through a backup and recovery regime (BCP/DRS) and system redundancy, and procedures for rapid isolation, investigation, notification, and reporting in the event of a breach incident are prepared in advance. In the financial sector, a breach incident must be reported to the supervisory authority without delay once recognized, so the regulatory reporting procedure must be included in the response manual along with technical recovery.
Availability protection includes preparation not only for disasters but also for mass traffic and fault propagation. When transfer requests concentrate at a particular time (the start of the month, payday, etc.), the load concentrates on the provider's API, and at this point processing delays lead to a surge of retries, creating the "fault propagation" risk of a spreading failure. To prevent this, load-control designs such as rate limiting, queuing, and exponential-backoff retries are put in place so that one institution's overload does not drag down the availability of the entire ecosystem. In other words, availability is the product of a comprehensive design that encompasses not only hardware redundancy but also traffic management.
| Item | Content |
|---|---|
| Encryption | Encrypt the transfer channel (TLS/mTLS) and stored data |
| Integrity & leak prevention | Prevent tampering of transferred data (signatures, hashing), detect and block leakage (DLP) |
| Misdelivery prevention | Re-confirm receiver identity and authorization, verify transfer target and scope |
| Disaster/calamity preparedness | Backup and recovery (BCP/DRS), secure continuity through redundancy |
| Incident response | Establish breach-incident isolation, investigation, notification, and regulatory-reporting procedures |
6. Comparison of Sender and Receiver Responsibilities and Application Cases
The sender and receiver share the same safeguard objectives, but the center of gravity of their risk differs. For the sender (information provider), the core is to send out "only upon a legitimate request, with the exact scope, to the correct receiver," so the weight falls on verifying the authenticity of the transfer request, authenticating the receiver, and minimizing the transfer scope. Conversely, for the receiver (MyData operator), the core is to "store the received mass information safely and use it only within the purpose," so the weight falls on storage encryption, access control, and preventing use beyond the purpose. If one fails to understand this difference and mechanically applies the same checklist to both sides, one will miss the risks that actually matter to each.
| Category | Sender (information provider) | Receiver (MyData operator) |
|---|---|---|
| Risk center | Misdelivery, over-transfer, request tampering | Leakage of stored information, use beyond purpose |
| Core control | Verify transfer request, authenticate receiver, minimize scope | Storage encryption, access control, use control |
| Representative incident | Transfer to another person, transfer broader than requested | Mass leakage of collected information, resale |
As concrete cases: (1) a case in which one operator's server misconfiguration loosened access-token verification so that another user's asset information was queried demonstrates the importance of access control and token management on the receiver side; (2) an over-transfer case in which a provider API returned all-period data broader than the requested scope (e.g., the past one year) demonstrates the necessity of scope verification on the sender side; and (3) the "weak link" problem — in which a small operator with weak security among hundreds of participating institutions becomes the attack surface for the entire ecosystem — demonstrates the justification for a certification and supervision regime that admits only institutions that have passed the security-conformance review of the standard API.
The common lesson of these cases is that transfer security is not a problem of a single technology but a problem of control design spanning the entire life cycle of request verification → transfer → storage → use. Even if an operator claims "we encrypt the transfer channel with TLS," if token verification is sloppy or stored information is in plaintext, the attacker will aim at the weakest point. Therefore inspection, too, must be performed not as a single item but as scenario-based inspection that threads the entire path (mock transfers and penetration tests assuming actual attack routes) to be effective.
7. Advanced — Linkage with Standards and Systems and Latest Trends
MyData transfer security is not complete as a standalone guide; it operates interlocked with various systems and standards. First, conformance with the standard API. Operators must use a standard API that has passed functional-conformance and security-conformance reviews, and the safeguards of this guide regulate operational security on top of that API. Second, mTLS and token security. Inter-institution trust is secured through mutual authentication (mTLS), and OAuth-based access tokens are designed with least privilege, short validity, and scope restriction to minimize damage when stolen.
Third, the extension of the right to request personal-data transfer to all fields. The right to request transfer, which started with financial MyData, is on a trajectory of expanding to the public and medical sectors through amendments to the Personal Information Protection Act, so transfer-security requirements are becoming a common task across all industries beyond finance (the detailed timing and scope of implementation may vary with the progress of the system, so definitive statements are avoided). Fourth, integration with zero trust. The zero-trust principle of verifying every transfer and every access — rather than "trusting because authentication was done once" — fits especially well with MyData transfers, which constantly cross institutional boundaries. Going forward, transfer security is expected to evolve from static checklists toward continuous verification and behavior-based detection.
A change worth noting in this trend is that the information subject to transfer is gradually broadening into the unstructured, high-volume, and real-time. Once it includes, beyond simple balances and transaction records, payment patterns, behavioral data, and even medical and health information, the sensitivity rises, and when combined with AI-based analysis, the re-identification and profiling risk grows. Therefore transfer security must broaden its scope, in addition to traditional controls such as encryption and access control, to controls at the use stage that also look at how the transferred information is combined and utilized. Pseudonymization and anonymization, blocking use beyond purpose, and managing combination histories are its concrete means.
8. Considerations and Implications (Professional Engineer's Perspective)
- A chain of trust across the entire transfer path: If any one of authentication, encryption, access control, and storage protection is weak, the whole collapses. The key is to design end-to-end trust by combining mTLS-based mutual authentication with short-lived, least-privilege tokens, and to periodically identify and reinforce the "weakest link."
- Satisfying standards and operational security in parallel: The standard API (functional and security conformance) and the safeguards of this guide are separate requirements that must both be met. Passing a conformance review does not guarantee security during operation, so operational security must be continuously verified through constant inspection and log analysis.
- Legal/institutional consistency and the effectiveness of administrative controls: While staying consistent with the safety-securing-measure standards of the Credit Information Act and the Personal Information Protection Act, maintain the effectiveness of administrative controls through periodic inspection, employee training, and drills so that they do not stop at documentation.
- Ecosystem trust is competitiveness: Because all participating institutions must maintain the same level of security, a certification and supervision regime that screens out weak participants and mutual-responsibility governance are preconditions for the spread of MyData. The security level should be seen not as a cost but as trust-based business competitiveness.
- Privacy by design: It is desirable to internalize transfer-scope minimization, purpose binding, and retention-period limits from the design stage, reducing risk structurally rather than through after-the-fact controls.
- Balance of availability and security: If strengthening security delays or halts transfers, that itself becomes an availability incident. Load control and redundancy must be designed together with security controls to manage the trade-off between safety and service continuity in an engineering manner.
References
- Personal Information Protection Commission and Financial Services Commission, guidance materials related to MyData (personal credit information management business), https://www.pipc.go.kr
- Financial Security Institute, MyData technical guidelines and standard API specifications, https://www.fsec.or.kr
- Act on the Use and Protection of Credit Information (Credit Information Act), https://www.law.go.kr
In one line: The MyData Transfer Security Guide commonly requires both sender and receiver to implement CPO designation, access management for the processing system (least privilege, MFA, access logs, anomaly detection), and transfer/storage protection with disaster preparedness (encryption, integrity, backup, incident response), so as to secure an end-to-end chain of trust for the sensitive information that constantly moves between institutions.